idnits 2.17.1 draft-wasserman-pcp-authentication-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 11, 2012) is 4422 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'IANAWEB' is mentioned on line 403, but not defined == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-23 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) 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: September 12, 2012 D. Zhang 6 Huawei 7 March 11, 2012 9 Port Control Protocol (PCP) Authentication Mechanism 10 draft-wasserman-pcp-authentication-02 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 September 12, 2012. 43 Copyright Notice 45 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 5 64 3.2. Session Termination . . . . . . . . . . . . . . . . . . . 7 65 3.3. Result Codes . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. PA Security Association . . . . . . . . . . . . . . . . . . . 7 67 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.1. Authentication OpCode Format . . . . . . . . . . . . . . . 8 69 5.2. Nonce Option . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.3. Authentication Tag Option . . . . . . . . . . . . . . . . 10 71 5.4. EAP Payload Option . . . . . . . . . . . . . . . . . . . . 11 72 5.5. PRF Option . . . . . . . . . . . . . . . . . . . . . . . . 11 73 5.6. Hash Algorithm Option . . . . . . . . . . . . . . . . . . 11 74 5.7. Session Lifetime Option . . . . . . . . . . . . . . . . . 12 75 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 12 76 6.1. Authentication Data Generation . . . . . . . . . . . . . . 12 77 6.2. Authentication Data Validation . . . . . . . . . . . . . . 12 78 6.3. Sequence Number . . . . . . . . . . . . . . . . . . . . . 13 79 6.4. Retransmission Policies . . . . . . . . . . . . . . . . . 13 80 6.5. MTU Considerations . . . . . . . . . . . . . . . . . . . . 14 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 84 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 10.1. Changes from -00 to -01 . . . . . . . . . . . . . . . . . 16 86 10.2. Changes from -01 to -02 . . . . . . . . . . . . . . . . . 16 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 89 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 Using the Port Control Protocol (PCP) [I-D.ietf-pcp-base], an IPv4 or 95 IPv6 host can flexibly manage the IP address mapping information on 96 its network address translators (NATs) and firewalls, and control 97 their policies in processing incoming and outgoing IP packets. 98 Because NATs and firewalls both play important roles in network 99 security architectures, there are many situations in which 100 authentication and access control are required to prevent un- 101 authorized users from accessing such devices. This document proposes 102 a PCP security extension which enables PCP servers to authenticate 103 the clients that they are communicating with using Extensible 104 Authentication Protocol (EAP). The following issues are considered 105 in the design of this extension: 107 o Loss of EAP messages during transportation 109 o Disordered delivery of EAP messages 111 o Generation of transport keys 113 o Integrity protection and data origin authentication for PCP 114 messages 116 o Algorithm agility 118 The mechanism described in this document meets the security 119 requirements to address the Advanced Threat Model described in the 120 base PCP specification [I-D.ietf-pcp-base]. This mechanism can be 121 used to secure PCP in the following situations:: 123 o On security infrastructure equipment, such as corporate firewalls, 124 that does not create implicit mappings. 126 o On equipment (such as CGNs or service provider firewalls) that 127 serve multiple administrative domains and do not have a mechanism 128 to securely partition traffic from those domains. 130 o For any implementation that wants to be more permissive in 131 authorizing explicit mappings than it is in authorizing implicit 132 mappings. 134 o For implementations that support the THIRD_PARTY Option (unless 135 they can meet the constraints outlined in Section 14.1.2.2). 137 o For implementations that wish to support any deployment scenario 138 that does not meet the constraints described in Section 14.1. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in RFC 2119 [RFC2119]. 146 Most of the terms used in this document are introduced in 147 [I-D.ietf-pcp-base]. 149 PCP Client (PCC): A PCP device (e.g., a host) which is responsible 150 for issuing PCP requests to a PCP server. In this document, a PCC is 151 also a EAP peer [RFC3748], and it is the responsibility of a PCC to 152 provide the credentials when authentication is required. 154 PCP Server (PCS): A PCP device (e.g., a NAT or a firewall) that 155 implements the server-side of the PCP protocol, via which PCCs 156 request and manage explicit mappings. In this document, a PCS is 157 integrated with an EAP authenticator [RFC3748]. Therefore, when 158 necessary, a PCS can verify the credentials provided by a PCC and 159 make an access control decision based on the authentication result. 161 PCP Authentication (PA) Session: A series of PCP message exchanges 162 transferred between a PCC and a PCS in order to perform 163 authentication, authorization, key distribution and secured PCP 164 communication. Each PA session is assigned a distinctive Session ID. 165 The PCP devices involved within a PA session are called session 166 partners. A typical PA session has two session partners. 168 Session Lifetime: The life period associated with a PA session, which 169 decided the lifetime of the current authorization given to the PCC. 171 PCP Security Association (PCP SA): A PCP security association is 172 formed between a PCC and a PCS by sharing cryptographic keying 173 material and associated context. The formed duplex security 174 association is used to protect the bidirectional PCP signaling 175 traffic between the PCC and PCS. 177 Master Session Key (MSK): A key derived by the partners of a PA 178 session, using a EAP key generating method specified in [RFC3748]. 180 PA (PCP for Authentication) message: A PCP message containing an 181 Authentication OpCode for EAP authentication. 183 3. Protocol Details 184 3.1. Session Initiation 186 To carry out an EAP authentication process between two PCP devices, a 187 set of PA messages need to be exchanged. Each PA message contains an 188 Authentication OpCode (and additional Options if needed). The 189 Authentication OpCode consists of four fields: Session ID, Flag, EAP 190 Type, and Sequence Number. The Session ID field is used to identify 191 the session which the message belongs to. The Flag field indicates 192 the type of the PCP message, while EAP Type is used to identify the 193 type of the attached EAP message. The sequence number field is used 194 to detect the disorder or the duplication occurred during packet 195 delivery. 197 The message exchanges conveyed within an PA session is introduced in 198 the remainder section. 200 When a PCC intends to initiate a PA session with a PCS, it sends a 201 PCC-Initiation message to the PCS. The Session ID and Sequence 202 Number fields of the Authentication OpCode in the PCC-Initiation 203 message are set as 0, and the I bit is set. the PCC also needs to 204 select a random nonce and append it with the PCC-Initiation message 205 in order to deal with off-line attacks. Specifically, the nonce is 206 transported within a nonce option. After receiving the PCC- 207 Initiation, if the PCS would like to initiate a PA session, it will 208 reply with a PA-Request which contains an EAP Identity Request. The 209 Sequence Number field in the PA-Request is set as 0, and the Session 210 ID field MUST be filled with the session identifier assigned by the 211 PCS for this session. the PA-Request also needs to be attached with 212 the nonce. Form now on, every PA message within this session must be 213 attached with the session identifier. Otherwise, the session partner 214 receiving the message will discard the message silently. If the PCC 215 intends to simplify the authentication process, it can append an EAP 216 Identity Response message within the PCC-Initiation request so as to 217 skip over the step of waiting for the EAP Identity Request and inform 218 the PCS that it would like to perform EAP authentication. 220 In the scenario where a PCS receives a non-PA PCP message from a PCC 221 which needs to be authenticated, the PCS can reply with a PA-Request 222 to initiate a PA session; the result code field of the PA-Request is 223 set as AUTHENTICATION-REQUIRED. In addition, the PCS MUST assign a 224 session ID for the session and transfer it within the PA-Request. In 225 the PA messages exchanged afterwards in this session, the session ID 226 MUST be appended. Therefore, in the subsequent communication, the 227 PCC can distinguish the messages in this session from those in other 228 sessions through the PCS IP address and the session ID. When the PCC 229 receives the initial PA-Request message from the PCS, it can reply 230 with a PA-Answer message to continue the session or silently discards 231 the request message according to its local policies. 233 In a PA session, PA-Request messages are sent from PCSs to PCCs while 234 PA-Answer messages are only sent from PCCs to PCSs. Correspondently, 235 an EAP request messages MUST be transported within a PA-Request 236 message, and an EAP answer messages MUST be transported within a PA- 237 Answer message. Particularly, when a PCP device receives a PA- 238 Request or a PA-Answer message from its partner, the PCP device needs 239 to reply with a PA-Acknowledge message to indicate that the message 240 has been received. This solution is used to deal with the conditions 241 where the device cannot generate a response within a pre-specified 242 period due to certain reasons (e.g., waiting for human input to 243 construct a EAP message). Therefore, the partner does not have to 244 un-necessarily retransfer the PCP message. 246 In this work, it is mandated for a PCC and a PCS to perform a key- 247 generating EAP method in authentication, and so a successful EAP 248 authentication process will result in a Master Session Key (MSK). If 249 the PCC and the PCS want to generate a traffic key using the MSK, 250 they need to agree upon a Pseudo-Random Function (PRF) for the 251 transport key derivation and a MAC algorithm to provide data origin 252 authentication for subsequent PCP packets. On this occasion, the PCS 253 needs to append the initial PA-Request message with a set of PRF 254 Options and MAC Algorithm Options. Each PRF Option (MAC Algorithm 255 Option) contains a PRF (MAC (Message Authentication Code) algorithm) 256 that the PCS supports. After receiving the request, the PCC selects 257 a PRF and a MAC algorithm which it intends to support, and sends back 258 a PA-Answer with a PRF Option and a MAC Algorithm Option for the 259 selected algorithms. 261 The last PA-Request message transported within a PA session carries 262 the EAP authentication and PCP authorization results. The last PA- 263 Request and PA-Answer messages MUST have their the 'C' (Complete) bit 264 set. 266 If the EAP authentication successes, the result code of the last PA- 267 Request is AUTHENTICATION-SUCCESS. In this case, before sending out 268 the PA-Request, the PCS must derive a transport key and use it to 269 generate digests to protect the integrity and authenticity of the PA- 270 Request and any subsequent PCP message. Such digests are transported 271 within Authentication Tag Options. In addition, the PA-Request needs 272 to be appended with a Session Lifetime Option which indicates the 273 life time of the PA session (i.e., the life time of the MSK). 275 If the EAP authentication fails, the result code of the last PA- 276 Request is AUTHENTICATION-FAILED. If the EAP authentication 277 successes but Authorization fails, the result code of the last PA- 278 Request is AUTHORIZATION-FAILED. In the latter two cases, the PA 279 session MUST be terminated immediately after the last PCP 280 authentication message exchange. 282 3.2. Session Termination 284 A PA session can be explicitly terminated by sending a termination- 285 indicating PA acknowledge message from either session partner. After 286 receiving a termination-indicating message from the session partner, 287 a PCP device MUST response with a termination-indicating PA 288 Acknowledge message and remove the PA SA immediately. When the 289 session partner initiating the termination process receives the 290 acknowledge message, it will remove the associated PA SA immediately. 292 3.3. Result Codes 294 Following result codes are defined in the solution: 296 XXX AUTHENTICATION-REQUIRED 298 XXX AUTHENTICATION-FAILED 300 XXX AUTHENTICATION-SUCCESS 302 XXX AUTHORIZATION-FAILED 304 4. PA Security Association 306 At the beginning a PA session, a session SHOULD generate a PA SA to 307 maintain its state information during the session. A The parameters 308 of a PA SA is listed as follows: 310 o IP address and UDP port number of the PCC 312 o IP address and UDP port number of the PCS 314 o Session Identifier 316 o Sequence number for the next outgoing PCP message 318 o Sequence number for the next incoming PCP message 320 o Last outgoing message payload 322 o Retransmission interval 324 o MSK 326 o MAC algorithm: The algorithm that the transport key should use to 327 generate digests for PCP messages. 329 o Pseudo-random function: The pseudo random function negotiated in 330 the initial PA-Request and PA-Answer exchange for the transport 331 key derivation 333 o Transport key: the key derived from the MSK to provide integrity 334 protection and data origin authentication for the messages in the 335 PA session. The life time of the transport key SHOULD be 336 identical to the life time of the session. 338 Particularly, the transport key is computed in the following way: 339 Transport key = prf(MSK, "IETF PCP"| Session_ID, key ID), where: 341 o The prf: The pseudo-random function assigned in the Pseudo-random 342 function parameter. 344 o MSK: The master session key generated by the EAP method. 346 o "IETF PCP": The ASCII code representation of the non-NULL 347 terminated string (excluding the double quotes around it). 349 o Session_ID: The ID of the session which the MSK is derived from 351 o Key ID: The ID assigned for the traffic key 353 5. Packet Format 355 5.1. Authentication OpCode Format 357 The following figure illustrates the format of an authentication 358 Opcode: 359 0 1 2 3 360 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 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Flags | EAP Message Type | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Session ID | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Sequence Number | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Flags: The Flags field is two octets. The following bits are 370 assigned: 372 0 1 373 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 |I C R A K T S E r r r r r r r r| 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 * I (Initiation): This bit is set in a PCC-Initiation message. 380 * C (Complete): If the message is the last PA-Request or PA- 381 Answer message in the session, this bit MUST be set. For other 382 messages, this bit MUST be cleared. 384 * R (Request): This bit is set in a PA-Request message. 386 * A (Answer): This bit is set in a PA-Answer message. 388 * K (acKnowledgement): This bit is set and only set in a PA- 389 Acknowledgement message. 391 * T (Termination): If this bit is set in a PA-Acknowledgement 392 message, the message is used for session-termination 393 indication. 395 * S (Fragmentation start): This bit is set in a PA message which 396 contain the first fragment of a EAP message. 398 * E (Fragmentation start): This bit is set in a PA message which 399 contain the last fragment of a EAP message. 401 Message Type: The Message Type field is two octets. This field is 402 used to indicate the type of the EAP message attached within the 403 message. Message Type allocation is managed by IANA [IANAWEB]. 405 Session ID: This field contains a 32-bit PA session identifier. 407 Sequence Number: This field contains a 32-bit sequence number. In 408 this solution, a sequence number needs to be incremented on every 409 new (non-retransmission) outgoing packet in order to provide 410 ordering guarantee for PCP. 412 5.2. Nonce Option 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Option Code | Reserved | Option-Length | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Nonce | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Nonce: A random 32 bits number which is transported within a PCC- 422 Initiate message and the correspondent reply message from the PCS. 424 5.3. Authentication Tag Option 426 0 1 2 3 427 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 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Option Code | Reserved | Option-Length | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Session ID | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Key ID | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | | 436 | Authentication Data (Variable) | 437 ~ ~ 438 | | 439 | | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 Option-Length: The length of the Authentication Tag Option (in 443 octet), including the 8 octet fixed header and the variable length 444 of the authentication data. 446 Session ID: A 32-bit field used to indicates the identifier of the 447 session that the message belongs to and identifies the secret key 448 used to create the message digest appended to the PCP message. 450 Key ID: The ID associated with the traffic key used to generate 451 authentication data. This field is filled with zero if MSK is 452 directly used to secure the message. 454 Authentication Data: A Variable length field that carries the 455 Message Authentication Code for the PCP packet. The generation of 456 the digest can be various according to the algorithms specified in 457 different PCP SAs. 459 5.4. EAP Payload Option 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Option Code | Reserved | Option-Length | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | | 467 | EAP Message | 468 ~ ~ 469 | | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 472 EAP Message: The EAP message transferred. Note this field MUST 473 end on a 32-bit boundary, padded with 0's when necessary. 475 5.5. PRF Option 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Option Code | Reserved | Option-Length | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | PRF | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 PRF: The pseudo-random Function which the sender supports to 486 generate a MSK. 488 5.6. Hash Algorithm Option 490 0 1 2 3 491 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Option Code | Reserved | Option-Length | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | MAC Algorithm | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 MAC Algorithm: The MAC algorithm which the sender supports to 499 generate authentication data. 501 5.7. Session Lifetime Option 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Option Code | Reserved | Option-Length | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Session Lifetime | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Session Lifetime: The life period of the PA Session, which is decided 511 by the authorization result. 513 6. Processing Rules 515 6.1. Authentication Data Generation 517 If a PCP SA is generated as the result of an successful EAP 518 authentication process, every subsequent PCP message within the 519 session needs carry an Authentication Tag Option which contains the 520 digest of the PCP message for data orgin authentication and integrity 521 protection. 523 Before generating a digest for a PCP message, a device needs to first 524 select a traffic key in the session and append the Authentication Tag 525 Option at the end of the protected PCP message. The length of the 526 Authentication Data field is decided by the MAC algorithm adopted in 527 the session. The device then fills the Session ID field and the PCP 528 SA ID field, and sets the Authentication Data field as 0. After 529 this, the device generates a digest for the PCP message with the MAC 530 algorithm and the selected traffic key, and input the generated 531 digest into the Authentication Data field. 533 6.2. Authentication Data Validation 535 When a device receives a PCP pacekt with an Authentication Tag 536 Option, it needs to use the session ID transported in the option to 537 locate the proper SA, and then find out the associated transport key 538 and the MAC algorithm. After storing the value of the Authentication 539 field of the Authentication Tag Option, the device fills the the 540 Authentication field with zeros. Then, the device generates a digest 541 for the packet with the transport key and the MAC algorithm found in 542 the first step. If the value of the newly generated digest is 543 identical to the stored one, the device can ensure that the packet 544 has not been tampered during the transportation. The validation 545 successes. Otherwise, the packet MUST be discarded. 547 6.3. Sequence Number 549 PCP adopts UDP to transport signaling messages. As an un-reliable 550 transporting protocol, UDP does not guarantee the ordered packet 551 delivery and does not provide any protection from packet loss. In 552 order to ensure the EAP messages are exchanged in a reliable way, 553 every PCP packet exchanged during EAP authentication must carries an 554 monotonically increased sequence number. During a PA session, a PCP 555 device needs to maintain two sequence numbers, one for incoming 556 packets and one for outgoing packets. When generating an outgoing 557 PCP packet, the device attaches the outgoing sequence number to the 558 packet and increments the sequence number by 1. When receiving a PCP 559 packet from its session partner, the device will not accept it if the 560 sequence number carried in the packet does not matche the incoming 561 sequence number the device maintains. 563 After confirming that the received packet is valid, the device 564 increments the incoming sequence number by 1. However, the above 565 rules are not applied to PA-Acknowledgement messages. When receiving 566 or sending out a PA-Acknowledgement message, the device does not 567 inicrease the correspondent sequence number. Another exception is 568 message retransmission. When a device does not receive any response 569 message from its session partner in a certain period, it needs to 570 retransmit the last sent message with a limited rate. The duplicate 571 messages and the original message MUST use the identical sequence 572 number. When the device receives such duplicate messages from its 573 session partner, it MUST tries to answer them by sending the last 574 outgoing message with a limited rate unless it has received another 575 valid message with a larger sequence number from its session. Note 576 that in these cases the incoming and outgoing sequence number will 577 not be affected by the message retransmission. 579 6.4. Retransmission Policies 581 This work provides a retransmission mechanism for reliable PA message 582 delivery. The timer, the variables, and the rules used in this 583 mechanism is mostly brought from PANA[RFC5191]. 585 The retransmission behavior is controlled and described by the 586 following variables: 588 RT: Retransmission timeout from the previous (re)transmission 590 IRT: Base value for RT for the initial retransmission 592 MRC: Maximum retransmission count 593 MRT: Maximum retransmiting time interval 595 RAND: Randomization factor 597 With each message transmission or retransmission, the sender sets RT 598 according to the rules given below. 600 If RT expires before receiving any reply, the sender re-calculates RT 601 and retransmits the message. Each of the computations of a new RT 602 include a randomization factor (RAND), which is a random number 603 chosen with a uniform distribution between -0.1 and +0.1. The 604 randomization factor is included to minimize the synchronization of 605 messages. The algorithm for choosing a random number does not need 606 to be cryptographically sound. The algorithm SHOULD produce a 607 different sequence of random numbers from each invocation. RT for 608 the first message retransmission is based on IRT: 610 RT = IRT 612 RT for each subsequent message retransmission is based on the 613 previous value of RT (RTprev): 615 RT = (2+RAND) * RTprev 617 MRT specifies an upper bound on the value of RT (disregarding the 618 randomization added by the use of RAND). If MRT has a value of 0, 619 there is no upper limit on the value of RT. Otherwise: 621 if (RT > MRT) 623 RT = (1+RAND) * MRT 625 MRC specifies an upper bound on the number of times a sender may 626 retransmit a message. Unless MRC is zero, the message exchange fails 627 once the sender has transmitted the message MRC times. In this case, 628 the sender needs to start a session termination process illustrated 629 in Section 3.2. 631 6.5. MTU Considerations 633 The fragmentation and reassembly of EAP messages must be provided in 634 order to ensure the length of a PA message is not larger than the MTU 635 of the link that it will be transported through. Therefore, a PA 636 message may only transport a fragment of an EAP message. Becasue any 637 loss or tamper of a EAP frgament will be detected and sequencing 638 information is provided, fragmentation support can be added in a 639 simple manner. Particularly, the S bit is set in a PA message which 640 contain the first fragment of a EAP message, and the The E bit is set 641 in a PA message which contain the last fragment of a EAP message. 643 7. IANA Considerations 645 TBD 647 8. Security Considerations 649 In this work, a successful EAP authentication process performed 650 between two PCP devices will result in the generation of a MSK which 651 can be used to derive the transport keys to generate MAC digests for 652 subsequent PCP message exchanges. This work does not exclude the 653 possibility of using the MSK to generate keys for different security 654 protocols to enable per-packet cryptographic protection. The methods 655 of deriving the transport key for the security protocols is out of 656 scope of this document. 658 However, before a transport key has been generated, the PA messages 659 exchanged within a PA session have little cryptographic protection, 660 and if there is no already established security channel between two 661 session partners, these messages are subject to man-in-the-middle 662 attacks and DOS attacks. For instance, the initial PA-Request and 663 PA-Answer exchange is vulnerable to spoofing attacks as these 664 messages are not authenticated and integrity protected. In order to 665 prevent very basic DOS attacks, a PCP device SHOULD generate state 666 information as little as possible in the initial PA-Request and PA- 667 Answer exchanges. The choice of EAP method is also very important. 668 The selected EAP method must be resilient to the attacks possibly 669 occurred in a insecure network environment, and the user-identity 670 confidentiality, protection against dictionary attacks, and session- 671 key establishment must be supported. 673 9. Acknowledgements 675 This document was written using the xml2rfc tool described in RFC 676 2629 [RFC2629]. 678 Some of the ideas in this document were adopted from PANA[RFC5191]. 680 10. Change Log 681 10.1. Changes from -00 to -01 683 o Editorial changes, added use cases to introduction. 685 10.2. Changes from -01 to -02 687 o Add a nonce into the first two exchanged PA message between the 688 PCC and PCS. When a PCC initiate the session, it can use the 689 nonce to detect offline attacks. 691 o Add the key ID field into the authentication tag option so that a 692 MSK can generate multiple traffic keys. 694 o Specify that when a PCP device receives a PA-Request or a PA- 695 Answer message from its partner the PCP device needs to reply with 696 a PA-Acknowledge message to indicate that the message has been 697 received. 699 o Add the support of fragmenting EAP messages. 701 11. References 703 11.1. Normative References 705 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 706 Requirement Levels", BCP 14, RFC 2119, March 1997. 708 11.2. Informative References 710 [I-D.ietf-pcp-base] 711 Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R. 712 Penno, "Port Control Protocol (PCP)", 713 draft-ietf-pcp-base-23 (work in progress), February 2012. 715 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 716 June 1999. 718 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 719 Levkowetz, "Extensible Authentication Protocol (EAP)", 720 RFC 3748, June 2004. 722 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 723 Yegin, "Protocol for Carrying Authentication for Network 724 Access (PANA)", RFC 5191, May 2008. 726 Authors' Addresses 728 Margaret Wasserman 729 Painless Security 730 356 Abbott Street 731 North Andover, MA 01845 732 USA 734 Phone: +1 781 405 7464 735 Email: mrw@painless-security.com 736 URI: http://www.painless-security.com 738 Sam Hartman 739 Painless Security 740 356 Abbott Street 741 North Andover, MA 01845 742 USA 744 Email: hartmans@painless-security.com 745 URI: http://www.painless-security.com 747 Dacheng Zhang 748 Huawei 749 Beijing, 750 China 752 Phone: 753 Fax: 754 Email: zhangdacheng@huawei.com 755 URI: