idnits 2.17.1 draft-ietf-pcp-authentication-04.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 (July 21, 2014) is 3561 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5191' is defined on line 1068, 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: January 22, 2015 D. Zhang 6 Huawei 7 July 21, 2014 9 Port Control Protocol (PCP) Authentication Mechanism 10 draft-ietf-pcp-authentication-04 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 January 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . 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 Indication 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 PCP Auth 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 . . . . . . . . . . . . . . . . . . . 21 89 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 90 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 11.1. Changes from wasserman-pcp-authentication-02 to ietf- 92 pcp-authentication-00 . . . . . . . . . . . . . . . . . 22 93 11.2. Changes from wasserman-pcp-authentication-01 to -02 . . 22 94 11.3. Changes from ietf-pcp-authentication-00 to -01 . . . . . 22 95 11.4. Changes from ietf-pcp-authentication-01 to -02 . . . . . 22 96 11.5. Changes from ietf-pcp-authentication-02 to -03 . . . . . 23 97 11.6. Changes from ietf-pcp-authentication-03 to -04 . . . . . 23 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 23 100 12.2. Informative References . . . . . . . . . . . . . . . . . 23 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 103 1. Introduction 105 Using the Port Control Protocol (PCP) [RFC6887], an IPv4 or IPv6 host 106 can flexibly manage the IP address mapping information on its network 107 address translators (NATs) and firewalls, and control their policies 108 in processing incoming and outgoing IP packets. Because NATs and 109 firewalls both play important roles in network security 110 architectures, there are many situations in which authentication and 111 access control are required to prevent un-authorized users from 112 accessing such devices. This document proposes a PCP security 113 extension which enables PCP servers to authenticate their clients 114 with Extensible Authentication Protocol (EAP). The EAP messages are 115 encapsulated within PCP packets during transportation. 117 The following issues are considered in the design of this extension: 119 o Loss of EAP messages during transportation 121 o Disordered delivery of EAP messages 123 o Generation of transport keys 125 o Integrity protection and data origin authentication for PCP 126 messages 128 o Algorithm agility 130 The mechanism described in this document meets the security 131 requirements to address the Advanced Threat Model described in the 132 base PCP specification [RFC6887]. This mechanism can be used to 133 secure PCP in the following situations:: 135 o On security infrastructure equipment, such as corporate firewalls, 136 that does not create implicit mappings. 138 o On equipment (such as CGNs or service provider firewalls) that 139 serve multiple administrative domains and do not have a mechanism 140 to securely partition traffic from those domains. 142 o For any implementation that wants to be more permissive in 143 authorizing explicit mappings than it is in authorizing implicit 144 mappings. 146 o For implementations that support the THIRD_PARTY Option (unless 147 they can meet the constraints outlined in Section 14.1.2.2). 149 o For implementations that wish to support any deployment scenario 150 that does not meet the constraints described in Section 14.1. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 156 document are to be interpreted as described in RFC 2119 [RFC2119]. 158 Most of the terms used in this document are introduced in [RFC6887]. 160 PCP Client: A PCP device (e.g., a host) which is responsible for 161 issuing PCP requests to a PCP server. In this document, a PCP client 162 is also a EAP peer [RFC3748], and it is the responsibility of a PCP 163 client to provide the credentials when authentication is required. 165 PCP Server: A PCP device (e.g., a NAT or a firewall) that implements 166 the server-side of the PCP protocol, via which PCP clients request 167 and manage explicit mappings. In this document, a PCP server is 168 integrated with an EAP authenticator [RFC3748]. Therefore, when 169 necessary, a PCP server can verify the credentials provided by a PCP 170 client and make an access control decision based on the 171 authentication result. 173 PCP-Authentication (PA) Session: A series of PCP message exchanges 174 transferred between a PCP client and a PCP server. The PCP message 175 involved within a session includes the PA messages used to perform 176 EAP authentication, key distribution and session management, and the 177 common PCP messages secured with the keys distributed during 178 authentication. Each PA session is assigned a distinctive Session 179 ID. 181 Session Partner: A PCP device involved within a PA session. Each PA 182 session has two session partners (a PCP server and a PCP client). 184 Session Lifetime: The life period associated with a PA session, which 185 decides the lifetime of the current authorization given to the PCP 186 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 PA 195 session, using an EAP key generating method (e.g., the one defined in 196 [RFC5448]). 198 PCP-Authentication (PA) message: A PCP message containing an 199 Authentication OpCode. Particularly, a PA message sent from a PCP 200 server to a PCP client is referred to as a PA-Server, while PA 201 message sent from a PCP client to a PCP server is referred to as a 202 PA-Client. Therefore, a PA-Server is actually a PCP response message 203 specified in [RFC6887], and a PA-Client is a PCP request message. 204 This document specifies an option, the Authentication Tag Option for 205 PCP Auth, to provide integrity protection and message origin 206 authentication for PA 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 PA session, a PCP client and a PCP server need 219 to exchange a series of PA messages in order to perform an EAP 220 authentication process. Each PA message is attached with an 221 Authentication OpCode and may optionally contain a set of Options for 222 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 PA session with a 230 PCP server, it sends a PA-Initiation message (a PA-Client message 231 with the result code "INITIATION") to the PCP server. In the 232 message, the Session ID and Sequence Number fields of the 233 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 PA-Initiation, if the PCP server agrees to 238 initiate a PA session with the PCP client, it will reply with a PA- 239 Server message which contains an EAP Identity Request, and the result 240 code field of this PA-Server message is set as AUTHENTICATION- 241 REQUIRED. In addition, the server MUST assign a random session 242 identifier to distinctly identify this session, and fill the 243 identifier into the Session ID field of the Authentication OpCode in 244 the PA-Server message. The Sequence Number field of the 245 Authentication OpCode is set as 0. If there is a nonce option in the 246 received PA-Initiation message, the PA-Server message 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 this message. From now on, every PCP message within this session 250 will be attached with this session identifier. When receiving a PA 251 message from an unknown session, a PCP device MUST discard the 252 message silently. If the PCP client intends to simplify the 253 authentication process, it MAY append an EAP Identity Response 254 message within the PA-Initiation message so as to inform the PCP 255 server that it would like to perform EAP authentication and skip the 256 step of waiting for the EAP Identity Request. 258 In the scenario where a PCP server receives a common PCP request 259 message from a PCP client which needs to be authenticated, the PCP 260 server can reply with a PA-Server message to initiate a PA session. 261 The result code field of this PA-Server message is set as 262 AUTHENTICATION-REQUIRED. In addition, the PCP server MUST assign a 263 session ID for the session and transfer it within the PA-Server 264 message. The Sequence Number field in the PA-Server is set as 0. In 265 the PA messages exchanged afterwards in this session, the session ID 266 MUST be used in order to help session partners distinguish the 267 messages within this session from those not within. When the PCP 268 client receives this initial PA-Server message from the PCP server, 269 it can reply with a PA-Client message or silently discard the request 270 message according to its local policies. In the PA-Client message, a 271 nonce option which consists of a random nonce MAY be appended. If 272 so, in the next PA-Server message, the PCP sever MUST forward the 273 nonce back within a nonce option. 275 In a PA session, an EAP request message is transported within a PA- 276 Server message, and an EAP answer message is transported within a PA- 277 Client message. EAP relies on the underlying protocol to provide 278 reliable transmission; any disordered delivery or loss of packets 279 occurred during transportation must be detected and addressed. 280 Therefore, after sending out a PA-Server message, the PCP server will 281 not send a new PA-Server message until it receives a PA-Client 282 message with a proper sequence number from the PCP client, and vice 283 versa. If a PCP device receives a PA message from its partner and 284 cannot generate a EAP response within a pre-specified period due to 285 certain reasons (e.g., waiting for human input to construct a EAP 286 message or waiting for the additional PA messages in order to 287 construct a complete EAP message), the PCP device MUST reply with a 288 PA-Acknowledge message (PA messages with a Received Packet Option) to 289 notify the packet has been received. This approach not only can 290 avoid un-necessarily retransmission of the PA message but also can 291 guarantee the reliable packet delivery in the conditions where a PCP 292 device needs to receive multiple PA messages before generating an EAP 293 response. 295 In this approach, it is mandated for a PCP client and a PCP server to 296 perform a key-generating EAP method in authentication. Therefore, 297 after a successful authentication procedure, a Master Session Key 298 (MSK) will be generated. If the PCP client and the PCP server want 299 to generate a traffic key using the MSK, they need to agree upon a 300 Pseudo-Random Function (PRF) for the transport key derivation and a 301 MAC algorithm to provide data origin authentication for subsequent 302 PCP packets. In order to do this, the PCP server needs to append a 303 set of PRF Options and MAC Algorithm Options to the initial PA-Server 304 message. Each PRF Option contains a PRF that the PCP server 305 supports, and each MAC Algorithm Option contains a MAC (Message 306 Authentication Code) algorithm that the PCP server supports. 307 Moreover, in the first PA-Server message, the server MAY also attach 308 a ID Indication Option to direct the client to choose correct 309 credentials.After receiving the options, the PCP client selects the 310 PRF and the MAC algorithm which it would like to use, and then attach 311 the associated PRF and MAC Algorithm Options to the next PA-Client 312 message. 314 After the EAP authentication, the PCP server sends out a PA-Server 315 message to indicate the EAP authentication and PCP authorization 316 results. If the EAP authentication succeeds, the result code of the 317 PA-Server message is AUTHENTICATION-SUCCEED. In this case, before 318 sending out the PA-Server message, the PCP server MUST generate a PCP 319 SA and use the derived transport key to generate a digest for the 320 message. The digest is transported within an Authentication Tag 321 Option for PCP Auth. A more detailed description of generating the 322 authentication data can be found in Section 7.1. In addition, the 323 PA-Server MAY also contain a Session Lifetime Option which indicates 324 the life-time of the PA session (i.e., the life-time of the MSK). 325 After receiving the PA-Server message, the PCP client then needs to 326 generate a PA-Client message as response. If the PCP client also 327 authenticates the PCP server, the result code of the PA-Client is 328 AUTHENTICATION-SUCCEED. In addition, the PCP client needs to 329 generate a PCP SA and uses the derived traffic key to secure the 330 message. From then on, all the PCP messages within the session are 331 secured with the traffic key and the MAC algorithm specified in the 332 PCP SA, unless a re-authentication is performed. 334 If a PCP client/server cannot authenticate its session partner, the 335 device sends out a PA message with the result code, AUTHENTICATION- 336 FAILED. If the EAP authentication succeeds but Authorization fails, 337 the device making the decision sends out a PA message with the result 338 code, AUTHORIZATION-FAILED. In these two cases, after the PA message 339 is sent out, the PA session MUST be terminated immediately. 341 3.2. Session Termination 343 A PA session can be explicitly terminated by sending a termination- 344 indicating PA message (a PA message with a result code "SESSION- 345 TERMINATION" ) from either session partner. After receiving a 346 Termination-Indicating message from the session partner, a PCP device 347 MUST respond with a Termination-Indicating PA message and remove the 348 PA SA immediately. When the session partner initiating the 349 termination process receives the PA message, it will remove the 350 associated PA SA immediately. 352 3.3. Session Re-Authentication 354 A session partner may select to perform EAP re-authentication if it 355 would like to update the PCP SA (e.g., update the MSK and rollback 356 the sequence numbers, or extend the session life period) without 357 initiating a new PA session. 359 When the PCP server would like to initiate a re-authentication, it 360 sends the PCP client a PA-Server message. The result code of the 361 message is set to "RE-AUTHENTICATION", which indicates the message is 362 for an re-authentication process. If the PCP client would like to 363 start the re-authentication, it will send an PA-Client message to the 364 PCP server, the result code of the PA-Client message is set to "RE- 365 AUTHENTICATION". Then, the session partners exchange PA messages to 366 transfer EAP messages for the re-authentication. During the re- 367 authentication procedure, the session partners protect the integrity 368 of PA messages with the key and MAC algorithm specified in the 369 current PCP SA; the sequence numbers associated with the packet will 370 never be rolled back and keep increasing according to Section 7.3. 372 If the EAP re-authentication succeeds, the result code of the last 373 PA-Server is "AUTHENTICATION-SUCCEED". In this case, before sending 374 out the PA-Server, the PCP server must update the SA and use the new 375 key to generate digests to protect the integrity and authenticity of 376 the PA-Server and any subsequent PCP message. In addition, the PA- 377 Server MAY be appended with a Session Lifetime Option which indicates 378 the new life-time of the PA session. 380 If the EAP authentication fails, the result code of the last PA- 381 Server is "AUTHENTICATION-FAILED". If the EAP authentication 382 succeeds but Authorization fails, the result code of the last PA- 383 Server is "AUTHORIZATION-FAILED". In the latter two cases, the PA 384 session MUST be terminated immediately after the last PA message 385 exchange. 387 4. PA Security Association 389 At the beginning of a PA session, a session SHOULD generate a PA SA 390 to maintain its state information during the session. The parameters 391 of a PA SA are listed as follows: 393 o IP address and UDP port number of the PCP client 395 o IP address and UDP port number of the PCP server 397 o Session Identifier 399 o Sequence number for the next outgoing PA message 401 o Sequence number for the next incoming PA message 403 o Sequence number for the next outgoing common PCP message (included 404 in the SA for PCP slient) 406 o Sequence number for the next incoming common PCP message (included 407 in the SA for PCP slient) 409 o Last outgoing message payload 411 o Retransmission interval 413 o MSK: The master session key generated by the EAP method. 415 o MAC algorithm: The algorithm that the transport key should use to 416 generate digests for PCP messages. 418 o Pseudo-random function: The pseudo random function negotiated in 419 the initial PA-Server and PA-Client exchange for the transport key 420 derivation 422 o Transport key: the key derived from the MSK to provide integrity 423 protection and data origin authentication for the messages in the 424 PA session. The life-time of the transport key SHOULD be 425 identical to the life-time of the session. 427 o The nonce selected by the PCP client at the initiation of the 428 session. 430 o Key ID: the ID associated with Transport key. 432 Particularly, the transport key is computed in the following way: 433 Transport key = prf(MSK, "IETF PCP"| Session_ID| Nonce| key ID), 434 where: 436 o The prf: The pseudo-random function assigned in the Pseudo-random 437 function parameter. 439 o MSK: The master session key generated by the EAP method. 441 o "IETF PCP": The ASCII code representation of the non-NULL 442 terminated string (excluding the double quotes around it). 444 o Session_ID: The ID of the session which the MSK is derived from. 446 o Nonce: The nonce selected by the client and transported in the 447 Initial PA-Client packet. If the PCP client does not select one, 448 this value is set as 0. 450 o Key ID: The ID assigned for the traffic key. 452 5. Result Code 454 This message use the result code field specified in the PCP headers 455 to transport the information for authentication and session 456 management. Particularly, the values of following result codes are 457 specified. 459 TBD INITIATION 461 TBD AUTHENTICATION-REQUIRED 463 TBD AUTHENTICATION-FAILED 465 TBD AUTHENTICATION-SUCCEED 467 TBD AUTHORIZATION-FAILED 469 TBD SESSION-TERMINATION 471 6. Packet Format 473 6.1. Packet Format of PCP Auth Messages 475 The format of PA-Server messages is identical to the response packet 476 format specified in Section 7.2 of [RFC6887]. 478 As illustrated in Figure 1, the PA-Client messages use the requester 479 header specified in Section 7.1 of[RFC6887]. The only difference is 480 that eight reserved bits are used to transfer the result codes (e.g., 481 "INITIATION", "AUTHENTICATION-FAILED"). Other fields in Figure 1 are 482 described in Section 7.1 of [RFC6887]. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Version = 2 |R| Opcode | Reserved | Result Code | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Requested Lifetime (32 bits) | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | | 492 | PCP Client's IP Address (128 bits) | 493 | | 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 : : 497 : Opcode-specific information : 498 : : 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 : : 501 : (optional) PCP Options : 502 : : 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Figure 1. PA-Client message Format 507 6.2. Authentication OpCode 509 The following figure illustrates the format of an authentication 510 OpCode: 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Session ID | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Sequence Number | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Session ID: This field contains a 32-bit PA session identifier. 522 Sequence Number: This field contains a 32-bit sequence number. In 523 this solution, a sequence number needs to be incremented on every 524 new (non-retransmission) outgoing packet in order to provide 525 ordering guarantee for PCP. 527 6.3. Nonce Option 529 Because the session identifier of PA session is determined by the PCP 530 server, a PCP client does not know the session identifier which will 531 be used when it sends out a PA-Initiation message. In order to 532 prevent an attacker from interrupting the authentication process by 533 sending off-line generated PA-Server messages, the PCP client needs 534 to generate a random number as nonce in the PA-Initiation message. 535 The PCP server will append the nonce within the initial PA-Server 536 message. If the PA-Server message does not carry the correct nonce, 537 the message will be discarded silently. 539 0 1 2 3 540 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 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Option Code | Reserved | Option-Length | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Nonce | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Option-Length: The length of the Nonce Option (in octet), 548 including the 4 octet fixed header and the variable length of the 549 authentication data. 551 Nonce: A random 32 bits number which is transported within a PCC- 552 Initiate message and the corresponding reply message from the PCP 553 server. 555 6.4. Authentication Tag Option for Common PCP 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Option Code | Reserved | Option-Length | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Session ID | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Sequence Number | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Key ID | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | | 568 | Authentication Data (Variable) | 569 ~ ~ 570 | | 571 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Because there is no authenticaiton OpCode in common PCP messages, the 575 authentication tag for common PCP messages needs to provide the 576 inforamtion of session ID and sequence numbers. 578 Option-Length: The length of the Authentication Tag Option for 579 Common PCP (in octet), including the 12 octet fixed header and the 580 variable length of the authentication data. 582 Session ID: A 32-bit field used to indicates the identifier of the 583 session that the message belongs to and identifies the secret key 584 used to create the message digest appended to the PCP message. 586 Sequence Number: This field contains a 32-bit sequence number. In 587 this solution, a sequence number needs to be incremented on every 588 new (non-retransmission) outgoing packet in order to provide 589 ordering guarantee for common PCP messages. 591 Key ID: The ID associated with the traffic key used to generate 592 authentication data. This field is filled with zero if MSK is 593 directly used to secure the message. 595 Authentication Data: A variable-length field that carries the 596 Message Authentication Code for the PCP packet. The generation of 597 the digest can be various according to the algorithms specified in 598 different PCP SAs. This field MUST end on a 32-bit boundary, 599 padded with 0's when necessary. 601 6.5. Authentication Tag Option for PCP Auth Messages 603 This option is used to provide message authentication for PA 604 messages. Compared with the Authentication Tag Option for Common 605 PCP, the session ID field and the sequence number field are removed 606 because such information is provided in the Authentication OpCode. 608 0 1 2 3 609 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 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | Option Code | Reserved | Option-Length | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Key ID | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | | 616 | Authentication Data (Variable) | 617 ~ ~ 618 | | 619 | | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Option-Length: The length of the Authentication Tag Option for PCP 623 Auth (in octet), including the 12 octet fixed header and the 624 variable length of the authentication data. 626 Key ID: The ID associated with the traffic key used to generate 627 authentication data. This field is filled with zero if MSK is 628 directly used to secure the message. 630 Authentication Data: A variable-length field that carries the 631 Message Authentication Code for the PCP packet. The generation of 632 the digest can be various according to the algorithms specified in 633 different PCP SAs. This field MUST end on a 32-bit boundary, 634 padded with 0's when necessary. 636 6.6. EAP Payload Option 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Option Code | Reserved | Option-Length | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | | 644 | EAP Message | 645 ~ ~ 646 | | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 Option-Length: The length of the EAP Payload Option (in octet), 650 including the 4 octet fixed header and the variable length of the 651 EAP message. 653 EAP Message: The EAP message transferred. Note this field MUST 654 end on a 32-bit boundary, padded with 0's when necessary. 656 6.7. PRF Option 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Option Code | Reserved | Option-Length | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | PRF | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Option-Length: The length of the PRF Option (in octet), including the 667 4 octet fixed header and the variable length of the EAP message. 669 PRF: The Pseudo-Random Function which the sender supports to generate 670 an MSK. This field contains an IKEv2 Transform ID of Transform Type 671 2 [RFC4306][RFC4868]. A PCP implementation MUST support 672 PRF_HMAC_SHA2_256 (5). 674 6.8. MAC Algorithm Option 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Option Code | Reserved | Option-Length | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | MAC Algorithm ID | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Option-Length: The length of the MAC Algorithm Option (in octet), 685 including the 4 octet fixed header and the variable length of the EAP 686 message. 688 MAC Algorithm ID: Indicate the MAC algorithm which the sender 689 supports to generate authentication data. The MAC Algorithm ID field 690 contains an IKEv2 Transform ID of Transform Type 3 691 [RFC4306][RFC4868].A PCP implementation MUST support 692 AUTH_HMAC_SHA2_256_128 (12). 694 6.9. Session Lifetime Option 696 0 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Option Code | Reserved | Option-Length | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Session Lifetime | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 Option-Length: The length of the Session Lifetime Option (in octet), 705 including the 4 octet fixed header and the variable length of the EAP 706 message. 708 Session Lifetime: The life time of the PA Session, which is decided 709 by the authorization result. 711 6.10. Received Packet Option 713 This option is used in a PA-Acknowledgement message to indicate a 714 packet with the contained sequence number has been received. 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Option Code | Reserved | Option-Length | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Received Sequence Number | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 Option-Length: The length of the Received Packet Option (in octet), 725 including the 4 octet fixed header and the variable length of the EAP 726 message. 728 Received Sequence Number: The sequence number of the last received 729 PCP packet. 731 6.11. ID Indication Option 733 This option provide the an identifier to the PCP client that the 734 client can use to choose which credentials to provide to the PCP 735 server. 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Option Code | Reserved | Option-Length | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | | 743 | ID Indicator | 744 ~ ~ 745 | | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 Option-Length: The length of the ID Indication Option (in octet), 749 including the 4 octet fixed header and the variable length of the 750 EAP message. 752 ID Indicator: The value for a PCP client to choose proper 753 credentials for authentication. The method of generating this 754 value is out of scope of this document. Note this field MUST end 755 on a 32-bit boundary, padded with 0's when necessary. 757 7. Processing Rules 759 7.1. Authentication Data Generation 761 If a PCP SA is generated as the result of a successful EAP 762 authentication process, every subsequent PCP message within the 763 session MUST carry an Authentication Tag Option which contains the 764 digest of the PCP message for data origin authentication and 765 integrity protection. 767 Before generating a digest for a PA message, a device needs to first 768 locate the PCP SA according to the session identifier and then get 769 the traffic key. Then the device appends an Authentication Tag 770 Option for PCP Auth at the end of the PCP Auth message. The length 771 of the Authentication Data field is decided by the MAC algorithm 772 adopted in the session. The device then fills the Key ID field with 773 the key ID of the traffic key, and sets the Authentication Data field 774 to 0. After this, the device generates a digest for the entire PCP 775 message (including the PCP header and Authentication Tag Option) 776 using the traffic key and the associated MAC algorithm, and insert 777 the generated digest into the Authentication Data field. 779 Similar to generating a digest for a PA message, before generating a 780 digest for a common PCP message, a device needs to first locate the 781 PCP SA according to the session identifier and then get the traffic 782 key. Then the device appends the Authentication Tag Option for 783 common PCP at the end of the message. The length of the 784 Authentication Data field is decided by the MAC algorithm adopted in 785 the session. The device then use the corresponding values derived 786 from the SA to fills the Session ID field, the Sequence Number field, 787 and the Key ID field, and sets the Authentication Data field to 0. 788 After this, the device generates a digest for the entire PCP message 789 (including the PCP header and Authentication Tag Option) using the 790 traffic key and the associated MAC algorithm, and inputs the 791 generated digest into the Authentication Data field. 793 7.2. Authentication Data Validation 795 When a device receives a common PCP packet with an Authentication Tag 796 Option for Common PCP, the device needs to use the session ID 797 transported in the option to locate the proper SA, and then find the 798 associated transport key (using key ID in the option) and the MAC 799 algorithm. If no proper SA or traffic key is found, the PCP packet 800 MUST be discarded silently. After storing the value of the 801 Authentication field of the Authentication Tag Option, the device 802 fills the Authentication field with zeros. Then, the device 803 generates a digest for the packet (including the PCP header and 804 Authentication Tag Option) with the transport key and the MAC 805 algorithm found in the first step. If the value of the newly 806 generated digest is identical to the stored one, the device can 807 ensure that the packet has not been tampered with, and the validation 808 succeeds. Otherwise, the packet MUST be discarded. 810 Similarly, when a device receives a PA message with an Authentication 811 Tag Option for PCP Auth, the device needs to use the session ID 812 transported in the opcode to locate the proper SA, and then find the 813 associated transport key (using key ID in the option) and the MAC 814 algorithm. If no proper SA or traffic key is found, the PCP packet 815 MUST be discarded silently. After storing the value of the 816 Authentication field of the Authentication Tag Option, the device 817 fills the Authentication field with zeros. Then, the device 818 generates a digest for the packet (including the PCP header and 819 Authentication Tag Option) with the transport key and the MAC 820 algorithm found in the first step. If the value of the newly 821 generated digest is identical to the stored one, the device can 822 ensure that the packet has not been tampered with, and the validation 823 succeeds. Otherwise, the packet MUST be discarded. 825 7.3. Retransmission Policies for PCP Auth Messages 827 Because EAP relies on the underlying protocols to provide reliable 828 transmission, after sending a PA message, a PCP client/server MUST 829 NOT send out any subsequent messages until receiving an expect PA 830 message (the PA message with a proper sequence number) from the peer. 831 If no such a message is received in a certain period, the PCP device 832 will re-send the last message according to certain retransmission 833 policies. This work reuses the retransmission policies specified in 834 the base PCP protocol (Section 8.1.1 of [RFC6887]). In the base PCP 835 protocol, such retransmission policies are only applied by PCP 836 clients. However, in this work, such retransmission policies are 837 also applied by the PCP servers. 839 Note that the last PA messages transported within the phases of 840 session initiation, session re-authentication, and session 841 termination do not have to follow the above policies since the 842 devices sending out those messages do not expect any further PA 843 messages. 845 When a device receives such a duplicate PA message from its session 846 partner, it MUST try to answer it by sending the last outgoing PA 847 message again. In order to achieve this function, the device needs 848 to maintain the last incoming and the assoicated outgoing packet. In 849 this case, if no outgoing PA message has been generated for the 850 received duplicate PA message yet, the device needs to generate a PA- 851 Acknowledgement message and sends it out. The rate of replying the 852 duplicate PA messages MUST be limited. 854 7.4. Sequence Numbers for PCP Auth Messages 856 PCP adopts UDP to transport signaling messages. As an un-reliable 857 transport protocol, UDP does not guarantee ordered packet delivery 858 and does not provide any protection from packet loss. In order to 859 ensure the EAP messages are exchanged in a reliable way, every PCP 860 packet exchanged during EAP authentication must carry an 861 monotonically increasing sequence number. During a PA session, a PCP 862 device needs to maintain two sequence numbers for PA messages, one 863 for incoming PA messages and one for outgoing PA messages. When 864 generating an outgoing PA packet, the device attaches the associated 865 outgoing sequence number to the packet and increments the sequence 866 number maintained in the SA by 1. When receiving a PA packet from 867 its session partner, the device will not accept it if the sequence 868 number carried in the packet does not match the incoming sequence 869 number the device maintains. After confirming that the received 870 packet is valid, the device increments the incoming sequence number 871 maintained in the SA by 1. 873 The above rules are not applied to PA-Acknowledgement messages (i.e., 874 PA messages containing a Received Packet Option). A PA- 875 Acknowledgement message does not transport any EAP message and only 876 indicate at a PA message is received. Therefore, the reliable 877 transmission of PA-Acknowledgement message does not have to be 878 guaranteed. For instance, after sending out a PA-Acknowledgement 879 message, a device generates a EAP response. In this case, the device 880 should send it to its session partner directly and need not to 881 confirm whether the PA-Acknowledgement message has been received by 882 its session partner or not. Therefore, when receiving or sending out 883 a PA-Acknowledgement message, the device MUST not increase the 884 corresponding sequence number stored in the SA. Otherwise, the lost 885 of a PA-Acknowledgement message during transportation will cause the 886 mismatching issues with the sequence numbers. 888 Another exception is in the message retransmission scenarios. When a 889 device does not receive any response from its session partner in a 890 certain period, it needs to retransmit the last outgoing PA message 891 with a limited rate. The duplicate messages and the original message 892 MUST use the identical sequence number. When the device receives 893 such a duplicate PA message from its session partner, it MUST try to 894 answer it by sending the last outgoing PA message again. Note the 895 rate of replying the duplicate PA messages must be limited. In such 896 cases, the maintained incoming and outgoing sequence numbers will not 897 be affected by the message retransmission. 899 7.5. Sequence Numbers for Common PCP Messages 901 When transporting common PCP messages within a PA session, a PCP 902 device needs to maintain a sequence number for outgoing common PCP 903 messages and a sequence number for incoming common PCP messages. 904 When generating a new outgoing PCP messages, the PCP device attaches 905 the outgoing sequence number for common PCP messages to the messages 906 and increments the sequence number maintained in the SA by 1. 908 When receiving a PCP packet from its session partner, the PCP device 909 will not accept it if the sequence number carried in the packet is 910 smaller than the incoming sequence number the server maintains. This 911 approach can protect the PCP server from replay attacks. After 912 confirming that the received packet is valid, the PCP server will use 913 the sequence number in the incoming packet to take place the incoming 914 sequence number for common PCP messages maintained in the SA. 916 Note that the sequence number in the incoming packet may not exactly 917 match the incoming sequence number maintained locally. In the base 918 PCP specification [RFC6887], a PCP client may stop retransmitting a 919 PCP request without receiving any expected PCP answer when the client 920 is no longer interested in the PCP transaction. After that, the PCP 921 client will try to generate new PCP requests for other purposes. In 922 this case, the sequence number in the new request will be larger than 923 the incoming sequence number maintained in the PCP server. 925 7.6. MTU Considerations 927 EAP methods are responsible for MTU handling, so no special 928 facilities are required in this protocol to deal with MTU issues. If 929 an EAP message is too long for a single PA message to transport, it 930 will be divided into multiple sections and transport them within 931 different PA messages. Note that the receiver may not be able to 932 know what to do in the next step until receiving all the sections and 933 constructing the complete EAP message. In this case, in order to 934 guarantee reliable message transmission, after receiving a PA 935 message, the receiver MUST reply with a PA-Acknowledgement message 936 until all the sections have been received. 938 8. IANA Considerations 940 TBD 942 9. Security Considerations 944 This section applies only to the in-band key management mechanism. 945 It will need to be updated if the WG choose to pursue the out-of-band 946 key management mechanism discussed above. 948 In this work, after a successful EAP authentication process performed 949 between two PCP devices, a MSK will be exported. The MSK can be used 950 to derive the transport keys to generate MAC digests for subsequent 951 PCP message exchanges. However, before a transport key has been 952 generated, the PA messages exchanged within a PA session have little 953 cryptographic protection, and if there is no already established 954 security channel between two session partners, these messages are 955 subject to man-in-the-middle attacks and DOS attacks. For instance, 956 the initial PA-Server and PA-Client exchange is vulnerable to 957 spoofing attacks as these messages are not authenticated and 958 integrity protected. In addition, because the PRF and MAC algorithms 959 are transported at this stage, an attacker may try to remove the PRF 960 and MAC options containing strong algorithms from the initial PA- 961 Server message and force the client choose the weakest algorithms. 962 Therefore, the server needs to guarantee that all the PRF and MAC 963 algorithms it provides support are strong enough. 965 In order to prevent very basic DOS attacks, a PCP device SHOULD 966 generate state information as little as possible in the initial PA- 967 Server and PA-Client exchanges. The choice of EAP method is also 968 very important. The selected EAP method must be resilient to the 969 attacks possibly in an insecure network environment, and the user- 970 identity confidentiality, protection against dictionary attacks, and 971 session-key establishment must be supported. 973 10. Acknowledgements 975 11. Change Log 977 11.1. Changes from wasserman-pcp-authentication-02 to ietf-pcp- 978 authentication-00 980 o Added discussion of in-band and out-of-band key management 981 options, leaving choice open for later WG decision. 983 o Removed support for fragmenting EAP messages, as that is handled 984 by EAP methods. 986 11.2. Changes from wasserman-pcp-authentication-01 to -02 988 o Add a nonce into the first two exchanged PCP-Auth message between 989 the PCP client and PCP server. When a PCP client initiate the 990 session, it can use the nonce to detect offline attacks. 992 o Add the key ID field into the authentication tag option so that a 993 MSK can generate multiple traffic keys. 995 o Specify that when a PCP device receives a PCP-Auth-Server or a 996 PCP-Auth-Client message from its partner the PCP device needs to 997 reply with a PCP-Auth-Acknowledge message to indicate that the 998 message has been received. 1000 o Add the support of fragmenting EAP messages. 1002 11.3. Changes from ietf-pcp-authentication-00 to -01 1004 o Editorial changes, added use cases to introduction. 1006 11.4. Changes from ietf-pcp-authentication-01 to -02 1008 o Add the support of re-authentication initiated by PCP server. 1010 o Specify that when a PCP device receives a PCP-Auth-Server or a 1011 PCP-Auth-Client message from its partner the PCP device MAY reply 1012 with a PCP-Auth-Acknowledge message to indicate that the message 1013 has been received. 1015 o Discuss the format of the PCP-Auth-Acknowledge message. 1017 o Remove the redundant information from the Auth OpCode, and specify 1018 new result codes transported in PCP packet headers 1020 o 1022 11.5. Changes from ietf-pcp-authentication-02 to -03 1024 o Change the name "PCP-Auth-Request" to "PCP-Auth-Server" 1026 o Change the name "PCP-Auth-Response" to "PCP-Auth-Client" 1028 o Specify two new sequence numbers for common PCP messages in the 1029 PCP SA, and describe how to use them 1031 o Specify a Authentication Tag Option for PCP Common Messages 1033 o Introduce the scenario where a EAP message has to be divided into 1034 multiple sections and transported in different PCP-Auth messages 1035 (for the reasons of MTU), and introduce how to use PCP-Auth- 1036 Acknowledge messages to ensure reliable packet delivery in this 1037 case. 1039 11.6. Changes from ietf-pcp-authentication-03 to -04 1041 o Change the name "PCP-Auth" to "PA". 1043 o Refine the retransmission policies. 1045 o Provide the discussion about how to instruct a PCP client to 1046 choose proper credential during authenticaiton, and an ID 1047 Indication Option is defined for that purpose. 1049 12. References 1051 12.1. Normative References 1053 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1054 Requirement Levels", BCP 14, RFC 2119, March 1997. 1056 12.2. Informative References 1058 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1059 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 1060 3748, June 2004. 1062 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 1063 4306, December 2005. 1065 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1066 384, and HMAC-SHA-512 with IPsec", RFC 4868, May 2007. 1068 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1069 Yegin, "Protocol for Carrying Authentication for Network 1070 Access (PANA)", RFC 5191, May 2008. 1072 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1073 Extensible Authentication Protocol Method for 3rd 1074 Generation Authentication and Key Agreement (EAP-AKA')", 1075 RFC 5448, May 2009. 1077 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 1078 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 1079 2013. 1081 Authors' Addresses 1083 Margaret Wasserman 1084 Painless Security 1085 356 Abbott Street 1086 North Andover, MA 01845 1087 USA 1089 Phone: +1 781 405 7464 1090 Email: mrw@painless-security.com 1091 URI: http://www.painless-security.com 1093 Sam Hartman 1094 Painless Security 1095 356 Abbott Street 1096 North Andover, MA 01845 1097 USA 1099 Email: hartmans@painless-security.com 1100 URI: http://www.painless-security.com 1102 Dacheng Zhang 1103 Huawei 1104 Beijing 1105 China 1107 Email: zhangdacheng@huawei.com