idnits 2.17.1 draft-ietf-pcp-authentication-03.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 PCP-Auth-Acknowledgement messages (i.e., PCP-Auth messages containing a Received Packet Option). A PCP-Auth-Acknowledgement message does not transport any EAP message and only indicate at a PCP-Auth message is received. Therefore, the reliable transmission of PCP-Auth-Acknowledgement message does not have to be guaranteed. Therefore, when receiving or sending out a PCP-Auth-Acknowledgement message, the device MUST not increase the corresponding sequence number stored in the SA. Otherwise, the lost of a PCP-Auth-Acknowledgement message during transportation will cause the mismatching issues with the sequence numbers. -- The document date (February 7, 2014) is 3728 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5191' is defined on line 1028, 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: August 11, 2014 D. Zhang 6 Huawei 7 February 7, 2014 9 Port Control Protocol (PCP) Authentication Mechanism 10 draft-ietf-pcp-authentication-03 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 August 11, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 69 6.1. Packet Format of PCP Auth Messages . . . . . . . . . . . 10 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 . . . . . 13 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 . . . . . . . . . . . . . . . . . 15 78 6.10. Received Packet Option . . . . . . . . . . . . . . . . . 16 79 7. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 16 80 7.1. Authentication Data Generation . . . . . . . . . . . . . 16 81 7.2. Authentication Data Validation . . . . . . . . . . . . . 17 82 7.3. Retransmission Policies for PCP Auth Messages . . . . . . 18 83 7.4. Sequence Numbers for PCP Auth Messages . . . . . . . . . 18 84 7.5. Sequence Numbers for Common PCP Messages . . . . . . . . 19 85 7.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 20 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 88 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 89 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 11.1. Changes from wasserman-pcp-authentication-02 to ietf- 91 pcp-authentication-00 . . . . . . . . . . . . . . . . . 21 92 11.2. Changes from wasserman-pcp-authentication-01 to -02 . . 21 93 11.3. Changes from ietf-pcp-authentication-00 to -01 . . . . . 21 94 11.4. Changes from ietf-pcp-authentication-01 to -02 . . . . . 21 95 11.5. Changes from ietf-pcp-authentication-02 to -03 . . . . . 22 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 98 12.1. Normative References . . . . . . . . . . . . . . . . . . 22 99 12.2. Informative References . . . . . . . . . . . . . . . . . 22 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 102 1. Introduction 104 Using the Port Control Protocol (PCP) [RFC6887], an IPv4 or IPv6 host 105 can flexibly manage the IP address mapping information on its network 106 address translators (NATs) and firewalls, and control their policies 107 in processing incoming and outgoing IP packets. Because NATs and 108 firewalls both play important roles in network security 109 architectures, there are many situations in which authentication and 110 access control are required to prevent un-authorized users from 111 accessing such devices. This document proposes a PCP security 112 extension which enables PCP servers to authenticate their clients 113 with Extensible Authentication Protocol (EAP). The EAP messages are 114 encapsulated within PCP packets during transportation. 116 The following issues are considered in the design of this extension: 118 o Loss of EAP messages during transportation 120 o Disordered delivery of EAP messages 122 o Generation of transport keys 124 o Integrity protection and data origin authentication for PCP 125 messages 127 o Algorithm agility 129 The mechanism described in this document meets the security 130 requirements to address the Advanced Threat Model described in the 131 base PCP specification [RFC6887]. This mechanism can be used to 132 secure PCP in the following situations:: 134 o On security infrastructure equipment, such as corporate firewalls, 135 that does not create implicit mappings. 137 o On equipment (such as CGNs or service provider firewalls) that 138 serve multiple administrative domains and do not have a mechanism 139 to securely partition traffic from those domains. 141 o For any implementation that wants to be more permissive in 142 authorizing explicit mappings than it is in authorizing implicit 143 mappings. 145 o For implementations that support the THIRD_PARTY Option (unless 146 they can meet the constraints outlined in Section 14.1.2.2). 148 o For implementations that wish to support any deployment scenario 149 that does not meet the constraints described in Section 14.1. 151 2. Terminology 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in RFC 2119 [RFC2119]. 157 Most of the terms used in this document are introduced in [RFC6887]. 159 PCP Client: A PCP device (e.g., a host) which is responsible for 160 issuing PCP requests to a PCP server. In this document, a PCP client 161 is also a EAP peer [RFC3748], and it is the responsibility of a PCP 162 client to provide the credentials when authentication is required. 164 PCP Server: A PCP device (e.g., a NAT or a firewall) that implements 165 the server-side of the PCP protocol, via which PCP clients request 166 and manage explicit mappings. In this document, a PCP server is 167 integrated with an EAP authenticator [RFC3748]. Therefore, when 168 necessary, a PCP server can verify the credentials provided by a PCP 169 client and make an access control decision based on the 170 authentication result. 172 PCP-Authentication (PCP-Auth) Session: A series of PCP message 173 exchanges transferred between a PCP client and a PCP server. The PCP 174 message involved within a session includes the PCP-Auth messages used 175 to perform EAP authentication, key distribution and session 176 management, and the common PCP messages secured with the keys 177 distributed during authentication. Each PCP-Auth session is assigned 178 a distinctive Session ID. 180 Session Partner: A PCP device involved within a PCP-Auth session. 181 Each PCP-Auth session has two session partners (a PCP server and a 182 PCP client). 184 Session Lifetime: The life period associated with a PCP-Auth session, 185 which decides the lifetime of the current authorization given to the 186 PCP client. 188 PCP Security Association (PCP SA): A PCP security association is 189 formed between a PCP client and a PCP server by sharing cryptographic 190 keying material and associated context. The formed duplex security 191 association is used to protect the bidirectional PCP signaling 192 traffic between the PCP client and PCP server. 194 Master Session Key (MSK): A key derived by the partners of a PCP-Auth 195 session, using an EAP key generating method (e.g., the one defined in 196 [RFC5448]). 198 PCP-Authentication (PCP-Auth) message: A PCP message containing an 199 Authentication OpCode. Particularly, a PCP-Auth message sent from a 200 PCP server to a PCP client is referred to as a PCP-Auth-Server, while 201 PCP-Auth message sent from a PCP client to a PCP server is referred 202 to as a PCP-Auth-Client. Therefore, a PCP-Auth-Server is actually a 203 PCP response message specified in [RFC6887], and a PCP-Auth-Client is 204 a PCP request message. This document specifies an option, the 205 Authentication Tag Option for PCP Auth, to provide integrity 206 protection and message origin authentication for PCP-Auth messages. 208 Common PCP message: A PCP message which does not contain an 209 Authentication OpCode. This document specifies an option, the 210 Authentication Tag Option for Common PCP, to provide integrity 211 protection and message origin authentication for the common PCP 212 messages. 214 3. Protocol Details 216 3.1. Session Initiation 218 At be beginning of a PCP-Auth session, a PCP client and a PCP server 219 need to exchange a series of PCP-Auth messages in order to perform an 220 EAP authentication process. Each PCP-Auth message is attached with 221 an Authentication OpCode and may optionally contain a set of Options 222 for various purposes (e.g., transporting authentication messages and 223 session managements). The Authentication OpCode consists of two 224 fields: Session ID and Sequence Number. The Session ID field is used 225 to identify the session to which the message belongs. The sequence 226 number field is used to detect the disorder or the duplication 227 occurred during packet delivery. 229 When a PCP client intends to proactively initiate a PCP-Auth session 230 with a PCP server, it sends a PCP-Auth-Initiation message (a PCP- 231 Auth-Client message with the result code "INITIATION") to the PCP 232 server. In the message, the Session ID and Sequence Number fields of 233 the Authentication OpCode are set as 0. The PCP client MAY also 234 optionally append a nonce option which consists of a random nonce 235 with the message. 237 After receiving the PCP-Auth-Initiation, if the PCP server agrees to 238 initiate a PCP-Auth session with the PCP client, it will reply with a 239 PCP-Auth-Server message which contains an EAP Identity Request, and 240 the result code field of this PCP-Auth-Server message is set as 241 AUTHENTICATION-REQUIRED. In addition, the server MUST assign a 242 session identifier which can distinctly identify this session, and 243 fill the identifier into the Session ID field of the Authentication 244 OpCode in the PCP-Auth-Server message. The Sequence Number field of 245 the Authentication OpCode is set as 0. If there is a nonce option in 246 the received PCP-Auth-Initiation message, the PCP-Auth-Server MUST be 247 attached with a nonce option so as to send the nonce value back. The 248 nonce will then be used by the PCP client to check the freshness of 249 the PCP-Auth-Server message. From now on, every PCP message within 250 this session will be attached with this session identifier. When 251 receiving a PCP-Auth message from an unknown session, a PCP device 252 MUST discard the message silently. If the PCP client intends to 253 simplify the authentication process, it MAY append an EAP Identity 254 Response message within the PCP-Auth-Initiation message so as to 255 inform the PCP server that it would like to perform EAP 256 authentication and skip the step of waiting for the EAP Identity 257 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 PCP-Auth-Server message to initiate a PCP- 262 Auth session. The result code field of this PCP-Auth-Server message 263 is set as AUTHENTICATION-REQUIRED. In addition, the PCP server MUST 264 assign a session ID for the session and transfer it within the PCP- 265 Auth-Server message. The Sequence Number field in the PCP-Auth- 266 Server is set as 0. In the PCP-Auth messages exchanged afterwards in 267 this session, the session ID MUST be used in order to help session 268 partners distinguish the messages within this session from those not 269 within. When the PCP client receives this initial PCP-Auth-Server 270 message from the PCP server, it can reply with a PCP-Auth-Client 271 message or silently discard the request message according to its 272 local policies. In the PCP-Auth-Client message, a nonce option which 273 consists of a random nonce MAY be appended. If so, in the next PCP- 274 Auth-Server message, the PCP sever MUST forward the nonce back within 275 a nonce option. 277 In a PCP-Auth session, an EAP request message is transported within a 278 PCP-Auth-Server message, and an EAP answer message is transported 279 within a PCP-Auth-Client message. EAP relies on the underlying 280 protocol to provide reliable transmission; any disordered delivery or 281 loss of packets occurred during transportation must be detected and 282 addressed. Therefore, after sending out a PCP-Auth-Server message, 283 the PCP server will not send a new PCP-Auth-Server message until it 284 receives a PCP-Auth-Client message with a proper sequence number from 285 the PCP client, and vice versa. If a PCP device receives a PCP-Auth 286 message from its partner and cannot generate a EAP response within a 287 pre-specified period due to certain reasons (e.g., waiting for human 288 input to construct a EAP message or waiting for the additional PCP- 289 Auth messages in order to construct a complete EAP message), the PCP 290 device MUST reply with a PCP-Auth-Acknowledge message (PCP-Auth 291 messages with a Received Packet Option) to notify the packet has been 292 received. This approach not only can avoid un-necessarily 293 retransmission of the PCP-Auth message but also can guarantee the 294 reliable packet delivery in the conditions where a PCP device needs 295 to receive multiple PCP-Auth messages before generating an EAP 296 response. 298 In this approach, it is mandated for a PCP client and a PCP server to 299 perform a key-generating EAP method in authentication. Therefore, 300 after a successful authentication procedure, a Master Session Key 301 (MSK) will be generated. If the PCP client and the PCP server want 302 to generate a traffic key using the MSK, they need to agree upon a 303 Pseudo-Random Function (PRF) for the transport key derivation and a 304 MAC algorithm to provide data origin authentication for subsequent 305 PCP packets. In order to do this, the PCP server needs to append a 306 set of PRF Options and MAC Algorithm Options to the initial PCP-Auth- 307 Server message. Each PRF Option contains a PRF that the PCP server 308 supports, and each MAC Algorithm Option contains a MAC (Message 309 Authentication Code) algorithm that the PCP server supports. After 310 receiving the options, the PCP client selects the PRF and the MAC 311 algorithm which it would like to use, and then attach the associated 312 PRF and MAC Algorithm Options to the next PCP-Auth-Client message. 314 After the EAP authentication, the PCP server sends out a PCP-Auth- 315 Server message to indicate the EAP authentication and PCP 316 authorization results. If the EAP authentication succeeds, the 317 result code of the PCP-Auth-Server message is AUTHENTICATION-SUCCEED. 318 In this case, before sending out the PCP-Auth-Server message, the PCP 319 server MUST generate a PCP SA and use the derived transport key to 320 generate a digest for the message. The digest is transported within 321 an Authentication Tag Option for PCP Auth. A more detailed 322 description of generating the authentication data can be found in 323 Section 7.1. In addition, the PCP-Auth-Server MAY also contain a 324 Session Lifetime Option which indicates the life-time of the PCP-Auth 325 session (i.e., the life-time of the MSK). After receiving the PCP- 326 Auth-Server message, the PCP client then needs to generate a PCP- 327 Auth-Client message as response. If the PCP client also 328 authenticates the PCP server, the result code of the PCP-Auth-Client 329 is 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 PCP-Auth message with the result code, 337 AUTHENTICATION-FAILED. If the EAP authentication succeeds but 338 Authorization fails, the device making the decision sends out a PCP- 339 Auth message with the result code, AUTHORIZATION-FAILED. In these 340 two cases, after the PCP-Auth message is sent out, the PCP-Auth 341 session MUST be terminated immediately. 343 3.2. Session Termination 345 A PCP-Auth session can be explicitly terminated by sending a 346 termination-indicating PCP-Auth message (a PCP-Auth message with a 347 result code "SESSION-TERMINATION" ) from either session partner. 348 After receiving a Termination-Indicating message from the session 349 partner, a PCP device MUST respond with a Termination-Indicating PCP- 350 Auth message and remove the PCP-Auth SA immediately. When the 351 session partner initiating the termination process receives the PCP- 352 Auth message, it will remove the associated PCP-Auth SA immediately. 354 3.3. Session Re-Authentication 356 A session partner may select to perform EAP re-authentication if it 357 would like to update the PCP SA (e.g., update the MSK and rollback 358 the sequence numbers, or extend the session life period) without 359 initiating a new PCP-Auth session. 361 When the PCP server would like to initiate a re-authentication, it 362 sends the PCP client a PCP-Auth-Server message. The result code of 363 the message is set to "RE-AUTHENTICATION", which indicates the 364 message is for an re-authentication process. If the PCP client would 365 like to start the re-authentication, it will send an PCP-Auth-Client 366 message to the PCP server, the result code of the PCP-Auth-Client 367 message is set to "RE-AUTHENTICATION". Then, the session partners 368 exchange PCP-Auth messages to transfer EAP messages for the re- 369 authentication. During the re-authentication procedure, the session 370 partners protect the integrity of PCP-Auth messages with the key and 371 MAC algorithm specified in the current PCP SA; the sequence numbers 372 associated with the packet will never be rolled back and keep 373 increasing according to Section 7.3. 375 If the EAP re-authentication succeeds, the result code of the last 376 PCP-Auth-Server is "AUTHENTICATION-SUCCEED". In this case, before 377 sending out the PCP-Auth-Server, the PCP server must update the SA 378 and use the new key to generate digests to protect the integrity and 379 authenticity of the PCP-Auth-Server and any subsequent PCP message. 380 In addition, the PCP-Auth-Server MAY be appended with a Session 381 Lifetime Option which indicates the new life-time of the PCP-Auth 382 session. 384 If the EAP authentication fails, the result code of the last PCP- 385 Auth-Server is "AUTHENTICATION-FAILED". If the EAP authentication 386 succeeds but Authorization fails, the result code of the last PCP- 387 Auth-Server is "AUTHORIZATION-FAILED". In the latter two cases, the 388 PCP-Auth session MUST be terminated immediately after the last PCP- 389 Auth message exchange. 391 4. PA Security Association 393 At the beginning of a PCP-Auth session, a session SHOULD generate a 394 PCP-Auth SA to maintain its state information during the session. 395 The parameters of a PCP-Auth SA are listed as follows: 397 o IP address and UDP port number of the PCP client 399 o IP address and UDP port number of the PCP server 401 o Session Identifier 403 o Sequence number for the next outgoing PCP-Auth message 405 o Sequence number for the next incoming PCP-Auth message 407 o Sequence number for the next outgoing common PCP message (included 408 in the SA for PCP slient) 410 o Sequence number for the next incoming common PCP message (included 411 in the SA for PCP slient) 413 o Last outgoing message payload 415 o Retransmission interval 417 o MSK: The master session key generated by the EAP method. 419 o MAC algorithm: The algorithm that the transport key should use to 420 generate digests for PCP messages. 422 o Pseudo-random function: The pseudo random function negotiated in 423 the initial PCP-Auth-Server and PCP-Auth-Client exchange for the 424 transport key derivation 426 o Transport key: the key derived from the MSK to provide integrity 427 protection and data origin authentication for the messages in the 428 PCP-Auth session. The life-time of the transport key SHOULD be 429 identical to the life-time of the session. 431 o The nonce selected by the PCP client at the initiation of the 432 session. 434 o Key ID: the ID associated with Transport key. 436 Particularly, the transport key is computed in the following way: 437 Transport key = prf(MSK, "IETF PCP"| Session_ID| Nonce| key ID), 438 where: 440 o The prf: The pseudo-random function assigned in the Pseudo-random 441 function parameter. 443 o MSK: The master session key generated by the EAP method. 445 o "IETF PCP": The ASCII code representation of the non-NULL 446 terminated string (excluding the double quotes around it). 448 o Session_ID: The ID of the session which the MSK is derived from. 450 o Nonce: The nonce selected by the client and transported in the 451 Initial PCP-Auth-Client packet. If the PCP client does not select 452 one, this value is set as 0. 454 o Key ID: The ID assigned for the traffic key. 456 5. Result Code 458 This message use the result code field specified in the PCP headers 459 to transport the information for authentication and session 460 management. Particularly, the values of following result codes are 461 specified. 463 TBD INITIATION 465 TBD AUTHENTICATION-REQUIRED 467 TBD AUTHENTICATION-FAILED 469 TBD AUTHENTICATION-SUCCEED 471 TBD AUTHORIZATION-FAILED 473 TBD SESSION-TERMINATION 475 6. Packet Format 477 6.1. Packet Format of PCP Auth Messages 479 The format of PCP-Auth-Server messages is identical to the response 480 packet format specified in Section 7.2 of [RFC6887]. 482 As illustrated in Figure 1, the PCP-Auth-Client messages use the 483 requester header specified in Section 7.1 of[RFC6887]. The only 484 difference is that eight reserved bits are used to transfer the 485 result codes (e.g., "INITIATION", "AUTHENTICATION-FAILED"). Other 486 fields in Figure 1 are described in Section 7.1 of [RFC6887]. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Version = 2 |R| Opcode | Reserved | Result Code | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Requested Lifetime (32 bits) | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | | 496 | PCP Client's IP Address (128 bits) | 497 | | 498 | | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 : : 501 : Opcode-specific information : 502 : : 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 : : 505 : (optional) PCP Options : 506 : : 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Figure 1. PCP-Auth-Client message Format 511 6.2. Authentication OpCode 513 The following figure illustrates the format of an authentication 514 OpCode: 516 0 1 2 3 517 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 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Session ID | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Sequence Number | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 Session ID: This field contains a 32-bit PCP-Auth session 525 identifier. 527 Sequence Number: This field contains a 32-bit sequence number. In 528 this solution, a sequence number needs to be incremented on every 529 new (non-retransmission) outgoing packet in order to provide 530 ordering guarantee for PCP. 532 6.3. Nonce Option 534 Because the session identifier of PCP-Auth session is determined by 535 the PCP server, a PCP client does not know the session identifier 536 which will be used when it sends out a PCP-Auth-Initiation message. 537 In order to prevent an attacker from interrupting the authentication 538 process by sending off-line generated PCP-Auth-Server messages, the 539 PCP client needs to generate a random number as nonce in the PCP- 540 Auth-Initiation message. The PCP server will append the nonce within 541 the initial PCP-Auth-Server message. If the PCP-Auth-Server message 542 does not carry the correct nonce, the message will be discarded 543 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 Option-Length: The length of the Authentication Tag Option for 581 Common PCP (in octet), including the 12 octet fixed header and the 582 variable length of the authentication data. 584 Session ID: A 32-bit field used to indicates the identifier of the 585 session that the message belongs to and identifies the secret key 586 used to create the message digest appended to the PCP message. 588 Sequence Number: This field contains a 32-bit sequence number. In 589 this solution, a sequence number needs to be incremented on every 590 new (non-retransmission) outgoing packet in order to provide 591 ordering guarantee for common PCP messages. 593 Key ID: The ID associated with the traffic key used to generate 594 authentication data. This field is filled with zero if MSK is 595 directly used to secure the message. 597 Authentication Data: A variable-length field that carries the 598 Message Authentication Code for the PCP packet. The generation of 599 the digest can be various according to the algorithms specified in 600 different PCP SAs. This field MUST end on a 32-bit boundary, 601 padded with 0's when necessary. 603 6.5. Authentication Tag Option for PCP Auth Messages 605 This option is used to provide message authentication for PCP-Auth 606 messages. Compared with the Authentication Tag Option for Common 607 PCP, the session ID field and the sequence number field are removed 608 because such information is provided in the Authentication OpCode. 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Option Code | Reserved | Option-Length | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Key ID | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | | 618 | Authentication Data (Variable) | 619 ~ ~ 620 | | 621 | | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Option-Length: The length of the Authentication Tag Option for PCP 625 Auth (in octet), including the 12 octet fixed header and the 626 variable length of the authentication data. 628 Key ID: The ID associated with the traffic key used to generate 629 authentication data. This field is filled with zero if MSK is 630 directly used to secure the message. 632 Authentication Data: A variable-length field that carries the 633 Message Authentication Code for the PCP packet. The generation of 634 the digest can be various according to the algorithms specified in 635 different PCP SAs. This field MUST end on a 32-bit boundary, 636 padded with 0's when necessary. 638 6.6. EAP Payload Option 640 0 1 2 3 641 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 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Option Code | Reserved | Option-Length | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | | 646 | EAP Message | 647 ~ ~ 648 | | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 Option-Length: The length of the EAP Payload Option (in octet), 652 including the 4 octet fixed header and the variable length of the 653 EAP message. 655 EAP Message: The EAP message transferred. Note this field MUST 656 end on a 32-bit boundary, padded with 0's when necessary. 658 6.7. PRF Option 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Option Code | Reserved | Option-Length | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | PRF | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 Option-Length: The length of the PRF Option (in octet), including the 669 4 octet fixed header and the variable length of the EAP message. 671 PRF: The Pseudo-Random Function which the sender supports to generate 672 an MSK. This field contains an IKEv2 Transform ID of Transform Type 673 2 [RFC4306][RFC4868]. A PCP implementation MUST support 674 PRF_HMAC_SHA2_256 (5). 676 6.8. MAC Algorithm Option 678 0 1 2 3 679 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 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Option Code | Reserved | Option-Length | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | MAC Algorithm ID | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Option-Length: The length of the MAC Algorithm Option (in octet), 687 including the 4 octet fixed header and the variable length of the EAP 688 message. 690 MAC Algorithm ID: Indicate the MAC algorithm which the sender 691 supports to generate authentication data. The MAC Algorithm ID field 692 contains an IKEv2 Transform ID of Transform Type 3 693 [RFC4306][RFC4868].A PCP implementation MUST support 694 AUTH_HMAC_SHA2_256_128 (12). 696 6.9. Session Lifetime Option 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Option Code | Reserved | Option-Length | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Session Lifetime | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Option-Length: The length of the Session Lifetime Option (in octet), 707 including the 4 octet fixed header and the variable length of the EAP 708 message. 710 Session Lifetime: The life time of the PCP-Auth Session, which is 711 decided by the authorization result. 713 6.10. Received Packet Option 715 This option is used in a PCP-Auth-Acknowledgement message to indicate 716 a packet with the contained sequence number has been received. 718 0 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Option Code | Reserved | Option-Length | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Received Sequence Number | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 Option-Length: The length of the Received Packet Option (in octet), 727 including the 4 octet fixed header and the variable length of the EAP 728 message. 730 Received Sequence Number: The sequence number of the last received 731 PCP packet. 733 7. Processing Rules 735 7.1. Authentication Data Generation 737 If a PCP SA is generated as the result of a successful EAP 738 authentication process, every subsequent PCP message within the 739 session MUST carry an Authentication Tag Option which contains the 740 digest of the PCP message for data origin authentication and 741 integrity protection. 743 Before generating a digest for a PCP-Auth message, a device needs to 744 first locate the PCP SA according to the session identifier and then 745 get the traffic key. Then the device appends an Authentication Tag 746 Option for PCP Auth at the end of the PCP Auth message. The length 747 of the Authentication Data field is decided by the MAC algorithm 748 adopted in the session. The device then fills the Key ID field with 749 the key ID of the traffic key, and sets the Authentication Data field 750 to 0. After this, the device generates a digest for the entire PCP 751 message (including the PCP header and Authentication Tag Option) 752 using the traffic key and the associated MAC algorithm, and insert 753 the generated digest into the Authentication Data field. 755 Similar to generating a digest for a PCP-Auth message, before 756 generating a digest for a common PCP message, a device needs to first 757 locate the PCP SA according to the session identifier and then get 758 the traffic key. Then the device appends the Authentication Tag 759 Option for common PCP at the end of the message. The length of the 760 Authentication Data field is decided by the MAC algorithm adopted in 761 the session. The device then use the corresponding values derived 762 from the SA to fills the Session ID field, the Sequence Number field, 763 and the Key ID field, and sets the Authentication Data field to 0. 764 After this, the device generates a digest for the entire PCP message 765 (including the PCP header and Authentication Tag Option) using the 766 traffic key and the associated MAC algorithm, and inputs the 767 generated digest into the Authentication Data field. 769 7.2. Authentication Data Validation 771 When a device receives a common PCP packet with an Authentication Tag 772 Option for Common PCP, the device needs to use the session ID 773 transported in the option to locate the proper SA, and then find the 774 associated transport key (using key ID in the option) and the MAC 775 algorithm. If no proper SA or traffic key is found, the PCP packet 776 MUST be discarded silently. After storing the value of the 777 Authentication field of the Authentication Tag Option, the device 778 fills the Authentication field with zeros. Then, the device 779 generates a digest for the packet (including the PCP header and 780 Authentication Tag Option) with the transport key and the MAC 781 algorithm found in the first step. If the value of the newly 782 generated digest is identical to the stored one, the device can 783 ensure that the packet has not been tampered with, and the validation 784 succeeds. Otherwise, the packet MUST be discarded. 786 Similarly, when a device receives a PCP Auth packet with an 787 Authentication Tag Option for PCP Auth, the device needs to use the 788 session ID transported in the opcode to locate the proper SA, and 789 then find the associated transport key (using key ID in the option) 790 and the MAC algorithm. If no proper SA or traffic key is found, the 791 PCP packet MUST be discarded silently. After storing the value of 792 the Authentication field of the Authentication Tag Option, the device 793 fills the Authentication field with zeros. Then, the device 794 generates a digest for the packet (including the PCP header and 795 Authentication Tag Option) with the transport key and the MAC 796 algorithm found in the first step. If the value of the newly 797 generated digest is identical to the stored one, the device can 798 ensure that the packet has not been tampered with, and the validation 799 succeeds. Otherwise, the packet MUST be discarded. 801 7.3. Retransmission Policies for PCP Auth Messages 803 Because EAP relies on the underlying protocols to provide reliable 804 transmission, after sending a PCP-Auth message, a PCP client/server 805 MUST NOT send out any subsequent messages until receiving an expect 806 PCP-Auth message (the PCP-Auth message with a proper sequence number) 807 from the peer. If no such a message is received in a certain period, 808 the PCP device will re-send the last message according to certain 809 retransmission policies. This work reuses the retransmission 810 policies specified in the base PCP protocol (Section 8.1.1 of 811 [RFC6887]). In the base PCP protocol, such retransmission policies 812 are only applied by PCP clients. However, in this work, such 813 retransmission policies are also applied by the PCP servers. 815 Note that the last PCP-Auth messages transported within the phases of 816 session initiation, session re-authentication, and session 817 termination do not have to follow the above policies since the 818 devices sending out those messages do not expect any further PCP-Auth 819 messages. 821 When a device receives such a duplicate PCP-Auth message from its 822 session partner, it MUST try to answer it by sending the last 823 outgoing PCP-Auth message again. The rate of replying the duplicate 824 PCP-Auth messages MUST be limited. 826 7.4. Sequence Numbers for PCP Auth Messages 828 PCP adopts UDP to transport signaling messages. As an un-reliable 829 transport protocol, UDP does not guarantee ordered packet delivery 830 and does not provide any protection from packet loss. In order to 831 ensure the EAP messages are exchanged in a reliable way, every PCP 832 packet exchanged during EAP authentication must carry an 833 monotonically increasing sequence number. During a PCP-Auth session, 834 a PCP device needs to maintain two sequence numbers for PCP-Auth 835 messages, one for incoming PCP-Auth messages and one for outgoing 836 PCP-Auth messages. When generating an outgoing PCP-Auth packet, the 837 device attaches the associated outgoing sequence number to the packet 838 and increments the sequence number maintained in the SA by 1. When 839 receiving a PCP-Auth packet from its session partner, the device will 840 not accept it if the sequence number carried in the packet does not 841 match the incoming sequence number the device maintains. After 842 confirming that the received packet is valid, the device increments 843 the incoming sequence number maintained in the SA by 1. 845 The above rules are not applied to PCP-Auth-Acknowledgement messages 846 (i.e., PCP-Auth messages containing a Received Packet Option). A 847 PCP-Auth-Acknowledgement message does not transport any EAP message 848 and only indicate at a PCP-Auth message is received. Therefore, the 849 reliable transmission of PCP-Auth-Acknowledgement message does not 850 have to be guaranteed. Therefore, when receiving or sending out a 851 PCP-Auth-Acknowledgement message, the device MUST not increase the 852 corresponding sequence number stored in the SA. Otherwise, the lost 853 of a PCP-Auth-Acknowledgement message during transportation will 854 cause the mismatching issues with the sequence numbers. 856 Another exception is in the message retransmission scenarios. When a 857 device does not receive any response from its session partner in a 858 certain period, it needs to retransmit the last outgoing PCP-Auth 859 message with a limited rate. The duplicate messages and the original 860 message MUST use the identical sequence number. When the device 861 receives such a duplicate PCP-Auth message from its session partner, 862 it MUST try to answer it by sending the last outgoing PCP-Auth 863 message again. Note the rate of replying the duplicate PCP-Auth 864 messages must be limited. In such cases, the maintained incoming and 865 outgoing sequence numbers will not be affected by the message 866 retransmission. 868 7.5. Sequence Numbers for Common PCP Messages 870 When transporting common PCP messages within a PCP-Auth session, a 871 PCP device needs to maintain a sequence number for outgoing common 872 PCP messages and a sequence number for incoming common PCP messages. 873 When generating a new outgoing PCP messages, the PCP device attaches 874 the outgoing sequence number for common PCP messages to the messages 875 and increments the sequence number maintained in the SA by 1. 877 When receiving a PCP packet from its session partner, the PCP device 878 will not accept it if the sequence number carried in the packet is 879 smaller than the incoming sequence number the server maintains. This 880 approach can protect the PCP server from replay attacks. After 881 confirming that the received packet is valid, the PCP server will use 882 the sequence number in the incoming packet to take place the incoming 883 sequence number for common PCP messages maintained in the SA. 885 Note that the sequence number in the incoming packet may not exactly 886 match the incoming sequence number maintained locally. In the base 887 PCP specification [RFC6887], a PCP client may stop retransmitting a 888 PCP request without receiving any expected PCP answer when the client 889 is no longer interested in the PCP transaction. After that, the PCP 890 client will try to generate new PCP requests for other purposes. In 891 this case, the sequence number in the new request will be larger than 892 the incoming sequence number maintained in the PCP server. 894 7.6. MTU Considerations 896 EAP methods are responsible for MTU handling, so no special 897 facilities are required in this protocol to deal with MTU issues. If 898 an EAP message is too long for a single PCP-Auth message to 899 transport, it will be divided into multiple sections and transport 900 them within different PCP-Auth messages. Note that the receiver may 901 not be able to know what to do in the next step until receiving all 902 the sections and constructing the complete EAP message. In this 903 case, in order to guarantee reliable message transmission, after 904 receiving a PCP-Auth message, the receiver MUST reply with a PCP- 905 Auth-Acknowledgement message until all the sections have been 906 received. 908 8. IANA Considerations 910 TBD 912 9. Security Considerations 914 This section applies only to the in-band key management mechanism. 915 It will need to be updated if the WG choose to pursue the out-of-band 916 key management mechanism discussed above. 918 In this work, after a successful EAP authentication process performed 919 between two PCP devices, a MSK will be exported. The MSK can be used 920 to derive the transport keys to generate MAC digests for subsequent 921 PCP message exchanges. However, before a transport key has been 922 generated, the PCP-Auth messages exchanged within a PCP-Auth session 923 have little cryptographic protection, and if there is no already 924 established security channel between two session partners, these 925 messages are subject to man-in-the-middle attacks and DOS attacks. 926 For instance, the initial PCP-Auth-Server and PCP-Auth-Client 927 exchange is vulnerable to spoofing attacks as these messages are not 928 authenticated and integrity protected. In addition, because the PRF 929 and MAC algorithms are transported at this stage, an attacker may try 930 to remove the PRF and MAC options containing strong algorithms from 931 the initial PCP-Auth-Server message and force the client choose the 932 weakest algorithms. Therefore, the server needs to guarantee that 933 all the PRF and MAC algorithms it provides support are strong enough. 935 In order to prevent very basic DOS attacks, a PCP device SHOULD 936 generate state information as little as possible in the initial PCP- 937 Auth-Server and PCP-Auth-Client exchanges. The choice of EAP method 938 is also very important. The selected EAP method must be resilient to 939 the attacks possibly in an insecure network environment, and the 940 user-identity confidentiality, protection against dictionary attacks, 941 and session-key establishment must be supported. 943 10. Acknowledgements 945 11. Change Log 947 11.1. Changes from wasserman-pcp-authentication-02 to ietf-pcp- 948 authentication-00 950 o Added discussion of in-band and out-of-band key management 951 options, leaving choice open for later WG decision. 953 o Removed support for fragmenting EAP messages, as that is handled 954 by EAP methods. 956 11.2. Changes from wasserman-pcp-authentication-01 to -02 958 o Add a nonce into the first two exchanged PCP-Auth message between 959 the PCP client and PCP server. When a PCP client initiate the 960 session, it can use the nonce to detect offline attacks. 962 o Add the key ID field into the authentication tag option so that a 963 MSK can generate multiple traffic keys. 965 o Specify that when a PCP device receives a PCP-Auth-Server or a 966 PCP-Auth-Client message from its partner the PCP device needs to 967 reply with a PCP-Auth-Acknowledge message to indicate that the 968 message has been received. 970 o Add the support of fragmenting EAP messages. 972 11.3. Changes from ietf-pcp-authentication-00 to -01 974 o Editorial changes, added use cases to introduction. 976 11.4. Changes from ietf-pcp-authentication-01 to -02 978 o Add the support of re-authentication initiated by PCP server. 980 o Specify that when a PCP device receives a PCP-Auth-Server or a 981 PCP-Auth-Client message from its partner the PCP device MAY reply 982 with a PCP-Auth-Acknowledge message to indicate that the message 983 has been received. 985 o Discuss the format of the PCP-Auth-Acknowledge message. 987 o Remove the redundant information from the Auth OpCode, and specify 988 new result codes transported in PCP packet headers 990 o 992 11.5. Changes from ietf-pcp-authentication-02 to -03 994 o Change the name "PCP-Auth-Request" to "PCP-Auth-Server" 996 o Change the name "PCP-Auth-Response" to "PCP-Auth-Client" 998 o Specify two new sequence numbers for common PCP messages in the 999 PCP SA, and describe how to use them 1001 o Specify a Authentication Tag Option for PCP Common Messages 1003 o Introduce the scenario where a EAP message has to be divided into 1004 multiple sections and transported in different PCP-Auth messages 1005 (for the reasons of MTU), and introduce how to use PCP-Auth- 1006 Acknowledge messages to ensure reliable packet delivery in this 1007 case. 1009 12. References 1011 12.1. Normative References 1013 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1014 Requirement Levels", BCP 14, RFC 2119, March 1997. 1016 12.2. Informative References 1018 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1019 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1020 3748, June 2004. 1022 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 1023 4306, December 2005. 1025 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC- 1026 SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1028 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1029 Yegin, "Protocol for Carrying Authentication for Network 1030 Access (PANA)", RFC 5191, May 2008. 1032 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1033 Extensible Authentication Protocol Method for 3rd 1034 Generation Authentication and Key Agreement (EAP-AKA')", 1035 RFC 5448, May 2009. 1037 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1038 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1039 2013. 1041 Authors' Addresses 1043 Margaret Wasserman 1044 Painless Security 1045 356 Abbott Street 1046 North Andover, MA 01845 1047 USA 1049 Phone: +1 781 405 7464 1050 Email: mrw@painless-security.com 1051 URI: http://www.painless-security.com 1053 Sam Hartman 1054 Painless Security 1055 356 Abbott Street 1056 North Andover, MA 01845 1057 USA 1059 Email: hartmans@painless-security.com 1060 URI: http://www.painless-security.com 1062 Dacheng Zhang 1063 Huawei 1064 Beijing 1065 China 1067 Email: zhangdacheng@huawei.com