idnits 2.17.1 draft-ietf-pcp-authentication-14.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 (July 20, 2015) is 3195 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5281 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). 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 Updates: 6887 (if approved) Painless Security 5 Intended status: Standards Track D. Zhang 6 Expires: January 21, 2016 Huawei 7 T. Reddy 8 Cisco 9 July 20, 2015 11 Port Control Protocol (PCP) Authentication Mechanism 12 draft-ietf-pcp-authentication-14 14 Abstract 16 An IPv4 or IPv6 host can use the Port Control Protocol (PCP) to 17 flexibly manage the IP address and port mapping information on 18 Network Address Translators (NATs) or firewalls to facilitate 19 communication with remote hosts. However, the un-controlled 20 generation or deletion of IP address mappings on such network devices 21 may cause security risks and should be avoided. In some cases the 22 client may need to prove that it is authorized to modify, create or 23 delete PCP mappings. This document describes an in-band 24 authentication mechanism for PCP that can be used in those cases. 25 The Extensible Authentication Protocol (EAP) is used to perform 26 authentication between PCP devices. 28 This document updates RFC6887. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 21, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . 5 68 3.1.1. Authentication triggered by the client . . . . . . . 6 69 3.1.2. Authentication triggered by the server . . . . . . . 7 70 3.1.3. Authentication using EAP . . . . . . . . . . . . . . 7 71 3.2. Recovery from lost PA session . . . . . . . . . . . . . . 9 72 3.3. Session Termination . . . . . . . . . . . . . . . . . . . 10 73 3.4. Session Re-Authentication . . . . . . . . . . . . . . . . 11 74 4. PA Security Association . . . . . . . . . . . . . . . . . . . 12 75 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.1. Packet Format of PCP Auth Messages . . . . . . . . . . . 13 77 5.2. Opcode-specific information of AUTHENTICATION Opcode . . 15 78 5.3. NONCE Option . . . . . . . . . . . . . . . . . . . . . . 16 79 5.4. AUTHENTICATION_TAG Option . . . . . . . . . . . . . . . . 16 80 5.5. PA_AUTHENTICATION_TAG option . . . . . . . . . . . . . . 18 81 5.6. EAP_PAYLOAD Option . . . . . . . . . . . . . . . . . . . 19 82 5.7. PRF Option . . . . . . . . . . . . . . . . . . . . . . . 19 83 5.8. MAC_ALGORITHM Option . . . . . . . . . . . . . . . . . . 20 84 5.9. SESSION_LIFETIME Option . . . . . . . . . . . . . . . . . 20 85 5.10. RECEIVED_PAK Option . . . . . . . . . . . . . . . . . . . 21 86 5.11. ID_INDICATOR Option . . . . . . . . . . . . . . . . . . . 21 87 6. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 22 88 6.1. Authentication Data Generation . . . . . . . . . . . . . 22 89 6.2. Authentication Data Validation . . . . . . . . . . . . . 23 90 6.3. Retransmission Policies for PA Messages . . . . . . . . . 24 91 6.4. Sequence Numbers for PCP Auth Messages . . . . . . . . . 24 92 6.5. Sequence Numbers for Common PCP Messages . . . . . . . . 25 93 6.6. MTU Considerations . . . . . . . . . . . . . . . . . . . 26 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 95 7.1. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 28 96 7.2. AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . . 28 97 7.3. PA_AUTHENTICATION_TAG . . . . . . . . . . . . . . . . . . 28 98 7.4. EAP_PAYLOAD . . . . . . . . . . . . . . . . . . . . . . . 29 99 7.5. PRF . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 100 7.6. MAC_ALGORITHM . . . . . . . . . . . . . . . . . . . . . . 29 101 7.7. SESSION_LIFETIME . . . . . . . . . . . . . . . . . . . . 30 102 7.8. RECEIVED_PAK . . . . . . . . . . . . . . . . . . . . . . 30 103 7.9. ID_INDICATOR . . . . . . . . . . . . . . . . . . . . . . 30 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 105 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 106 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 32 107 10.1. Changes from wasserman-pcp-authentication-02 to ietf- 108 pcp-authentication-00 . . . . . . . . . . . . . . . . . 32 109 10.2. Changes from wasserman-pcp-authentication-01 to -02 . . 32 110 10.3. Changes from ietf-pcp-authentication-00 to -01 . . . . . 32 111 10.4. Changes from ietf-pcp-authentication-01 to -02 . . . . . 32 112 10.5. Changes from ietf-pcp-authentication-02 to -03 . . . . . 33 113 10.6. Changes from ietf-pcp-authentication-03 to -04 . . . . . 33 114 10.7. Changes from ietf-pcp-authentication-04 to -05 . . . . . 33 115 10.8. Changes from ietf-pcp-authentication-05 to -06 . . . . . 33 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 117 11.1. Normative References . . . . . . . . . . . . . . . . . . 34 118 11.2. Informative References . . . . . . . . . . . . . . . . . 35 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 121 1. Introduction 123 Using the Port Control Protocol (PCP) [RFC6887], an application can 124 flexibly manage the IP address mapping information on its network 125 address translators (NATs) and firewalls, and control their policies 126 in processing incoming and outgoing IP packets. Because NATs and 127 firewalls both play important roles in network security 128 architectures, there are many situations in which authentication and 129 access control are required to prevent un-authorized users from 130 accessing such devices. This document defines a PCP security 131 extension that enables PCP servers to authenticate their clients with 132 Extensible Authentication Protocol (EAP). The EAP messages are 133 encapsulated within PCP messages during transportation. 135 The following issues are considered in the design of this extension: 137 o Loss of EAP messages during transportation 139 o Reordered delivery of EAP messages 141 o Generation of transport keys 142 o Integrity protection and data origin authentication for PCP 143 messages 145 o Algorithm agility 147 The mechanism described in this document meets the security 148 requirements to address the Advanced Threat Model described in the 149 base PCP specification [RFC6887]. This mechanism can be used to 150 secure PCP in the following situations: 152 o On security infrastructure equipment, such as corporate firewalls, 153 that do not create implicit mappings for specific traffic. 155 o On equipment (such as CGNs or service provider firewalls) that 156 serve multiple administrative domains and do not have a mechanism 157 to securely partition traffic from those domains. 159 o For any implementation that wants to be more permissive in 160 authorizing applications to create mappings for successful inbound 161 communications destined to machines located behind a NAT or a 162 firewall. 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 Most of the terms used in this document are introduced in [RFC6887]. 172 PCP Client: A PCP software instance that is responsible for issuing 173 PCP requests to a PCP server. In this document, a PCP client is also 174 a EAP peer [RFC3748], and it is the responsibility of a PCP client to 175 provide the credentials when authentication is required. 177 PCP Server: A PCP software instance that resides on the PCP- 178 Controlled Device that receives PCP requests from the PCP client and 179 creates appropriate state in response to that request. In this 180 document, a PCP server is integrated with an EAP authenticator 181 [RFC3748]. Therefore, when necessary, a PCP server can verify the 182 credentials provided by a PCP client and make an access control 183 decision based on the authentication result. 185 PCP-Authentication (PA) Session: A series of PCP message exchanges 186 transferred between a PCP client and a PCP server. The PCP messages 187 involved within a session includes the PA messages used to perform 188 EAP authentication, key distribution and session management, and the 189 common PCP messages secured with the keys distributed during 190 authentication. Each PA session is assigned a distinctive Session 191 ID. 193 Session Partner: A PCP implementation involved within a PA session. 194 Each PA session has two session partners (a PCP server and a PCP 195 client). 197 PCP device: A PCP client or a PCP server. 199 Session Lifetime: The lifetime associated with a PA session, which 200 decides the lifetime of the current authorization given to the PCP 201 client. 203 PCP Security Association (PCP SA): A PCP security association is 204 formed between a PCP client and a PCP server by sharing cryptographic 205 keying material and associated context. The formed duplex security 206 association is used to protect the bidirectional PCP signaling 207 traffic between the PCP client and PCP server. 209 Master Session Key (MSK): A key derived by the partners of a PA 210 session, using an EAP key generating method (e.g., the one defined in 211 [RFC5448]). 213 PCP-Authentication (PA) message: A PCP message containing an 214 AUTHENTICATION Opcode. Particularly, a PA message sent from a PCP 215 server to a PCP client is referred to as a PA-Server message, while a 216 PA message sent from a PCP client to a PCP server is referred to as a 217 PA-Client message. Therefore, a PA-Server message is actually a PCP 218 response message specified in [RFC6887], and a PA-Client message is a 219 PCP request message. This document specifies an option, the 220 PA_AUTHENTICATION_TAG Option defined in Section 5.5 for PCP 221 authentication, to provide integrity protection and message origin 222 authentication for PA messages. 224 Common PCP message: A PCP message which does not contain an 225 AUTHENTICATION Opcode. This document specifies an AUTHENTICATION_TAG 226 Option to provide integrity protection and message origin 227 authentication for the common PCP messages. 229 3. Protocol Details 231 3.1. Session Initiation 233 At the beginning of a PA session, a PCP client and a PCP server need 234 to exchange a series of PA messages in order to perform an EAP 235 authentication process. Each PA message MUST contain an 236 AUTHENTICATION Opcode and may optionally contain a set of Options for 237 various purposes (e.g., transporting authentication messages and 238 session management). The opcode-specific information in a 239 AUTHENTICATION Opcode consists of two fields : Session ID and 240 Sequence Number. The Session ID field is used to identify the PA 241 session to which the message belongs. The sequence number field is 242 used to detect whether reordering or duplication occurred during 243 message delivery. 245 3.1.1. Authentication triggered by the client 247 When a PCP client intends to proactively initiate a PA session with a 248 PCP server, it sends a PA-Initiation message (a PA-Client message 249 with the result code "INITIATION") to the PCP server. Section 5.1 250 updates the PCP request message format with result codes for the PCP 251 Authentication mechanism. In the opcode-specific information of the 252 message, the Session ID and Sequence Number fields are set as 0. The 253 PA-Client message MUST also contain a NONCE option defined in 254 Section 5.3 which consists of a random nonce. 256 After receiving the PA-Initiation, if the PCP server agrees to 257 initiate a PA session with the PCP client, it will reply with a PA- 258 Server message which contains an EAP Request and the result code 259 field of this PA-Server message is set to AUTHENTICATION_REQUEST. In 260 addition, the server MUST assign a unique session identifier to 261 distinctly identify this session, and fill the identifier into the 262 Session ID field in the opcode-specific information of the PA-Server 263 message. The Sequence Number field of the message is set as 0. The 264 PA-Server message MUST contain a NONCE option so as to send the nonce 265 value back. The nonce will then be used by the PCP client to check 266 the freshness of this message. Subsequent PCP messages within this 267 PA session MUST contain this session identifier. 269 PCP PCP 270 client server 271 |-- PA-Initiation-------------------------------->| 272 | (Seq=0, rc=INITIATION, Session ID=0) | 273 | | 274 |<-- PA-Server -----------------------------------| 275 | (Seq=0, Session ID=X, EAP request, | 276 | rc=AUTHENTICATION_REQUEST) | 277 | | 278 |-- PA-Client ----------------------------------->| 279 | (Seq=1, Session ID=X, EAP response, | 280 | rc=AUTHENTICATION_REPLY) | 281 | | 282 |<-- PA-Server -----------------------------------| 283 | (Seq=1, Session ID=X, EAP request, | 284 | rc=AUTHENTICATION_REQUEST) | 286 3.1.2. Authentication triggered by the server 288 In the scenario where a PCP server receives a common PCP request 289 message from a PCP client which needs to be authenticated, the PCP 290 server rejects the request with a AUTHENTICATION_REQUIRED error code 291 and can reply with a unsolicited PA-Server message to initiate a PA 292 session. The result code field of this PA-Server message is set to 293 AUTHENTICATION_REQUEST. In addition, the PCP server MUST assign a 294 Session ID for the session and transfer it within the PA-Server 295 message. The Sequence Number field in the PA-Server message is set 296 as 0. If the PCP client retries the common request before EAP 297 authentication is successful then it will receive 298 AUTHENTICATION_REQUIRED error code from the PCP server. In the PA 299 messages exchanged afterwards in this session, the Session ID will be 300 used in order to help session partners distinguish the messages 301 within this session from those not within. When the PCP client 302 receives this initial PA-Server message from the PCP server, it can 303 reply with a PA-Client message or silently discard the request 304 message according to its local policies. In the PA-Client message, a 305 NONCE option which consists of a random nonce MAY be appended. If 306 so, in the next PA-Server message, the PCP server MUST forward the 307 nonce back within a NONCE option. 309 PCP PCP 310 client server 311 |-- Common PCP request--------------------------->| 312 | | 313 |<- Common PCP response---------------------------| 314 | rc=AUTHENTICATION_REQUIRED) | 315 | | 316 |<-- PA-Server -----------------------------------| 317 | (Seq=0, Session ID=X, EAP request) | 318 | rc=AUTHENTICATION_REQUEST) | 319 | | 320 |-- PA-Client ----------------------------------->| 321 | (Seq=0, Session ID=X, EAP response) | 322 | rc=AUTHENTICATION_REPLY) | 323 | | 324 |<-- PA-Server -----------------------------------| 325 | (Seq=1, Session ID=X, EAP request, | 326 | rc=AUTHENTICATION_REQUEST) | 328 3.1.3. Authentication using EAP 330 In a PA session, an EAP request message is transported within a PA- 331 Server message and an EAP response message is transported within a 332 PA-Client message. EAP relies on the underlying protocol to provide 333 reliable transmission; any reordered delivery or loss of packets 334 occurring during transportation must be detected and addressed. 335 Therefore, after sending out a PA-Server message, the PCP server will 336 not send a new PA-Server message in the same PA session until it 337 receives a PA-Client message with a proper sequence number from the 338 PCP client, and vice versa. If a PCP client receives a PA message 339 containing an EAP request and cannot generate an EAP response 340 immediately due to certain reasons (e.g., waiting for human input to 341 construct a EAP message or due to EAP message fragmentation waiting 342 for the additional PA messages in order to construct a complete EAP 343 message), the PCP device MUST reply with a PA-Acknowledgement message 344 (PA message with a RECEIVED_PAK Option) to indicate that the message 345 has been received. This approach not only can avoid unnecessary 346 retransmission of the PA message but also can guarantee the reliable 347 message delivery in conditions where a PCP device needs to receive 348 multiple PA messages carrying the fragmented EAP request before 349 generating an EAP response. The number of EAP messages exchanged 350 between the PCP client and PCP server depends on the EAP method used 351 for authentication. 353 In this approach, PCP client and a PCP server MUST perform a key- 354 generating EAP method in authentication. Particularly, a PCP 355 authentication implementation MUST support EAP-TTLS [RFC5281] and 356 SHOULD support TEAP [RFC7170]. Therefore, after a successful 357 authentication procedure, a Master Session Key (MSK) will be 358 generated. If the PCP client and the PCP server want to generate a 359 transport key using the MSK, they need to agree upon a Pseudo-Random 360 Function (PRF) for the transport key derivation and a MAC algorithm 361 to provide data origin authentication for subsequent PCP messages. 362 In order to do this, the PCP server needs to append a set of PRF 363 Options and MAC_ALGORITHM Options to the initial PA-Server message. 364 Each PRF Option contains a PRF that the PCP server supports, and each 365 MAC_ALGORITHM Option contains a MAC (Message Authentication Code) 366 algorithm that the PCP server supports. Moreover, in the first PA- 367 Server message, the server MAY also attach an ID_INDICATOR Option 368 defined in Section 5.11 to direct the client to choose correct 369 credentials. After receiving the options, the PCP client MUST select 370 the PRF and the MAC algorithm which it would like to use, and then 371 adds the associated PRF and MAC Algorithm Options to the next PA- 372 Client message. 374 After the EAP authentication, the PCP server sends out a PA-Server 375 message to indicate the EAP authentication and PCP authorization 376 results. If the EAP authentication succeeds, the result code of the 377 PA-Server message is AUTHENTICATION_SUCCEEDED. In this case, before 378 sending out the PA-Server message, the PCP server MUST update the PCP 379 SA with the MSK and transport key, and use the derived transport key 380 to generate a digest for the message. The digest is transported 381 within an PA_AUTHENTICATION_TAG Option for PCP Auth. A more detailed 382 description of generating the authentication data can be found in 383 Section 6.1. In addition, the PA-Server message MUST also contain a 384 SESSION_LIFETIME Option defined in Section 5.9 which indicates the 385 lifetime of the PA session (i.e., the lifetime of the MSK). After 386 receiving the PA-Server message, the PCP client then needs to 387 generate a PA-Client message as response. If the PCP client also 388 authenticates the PCP server, the result code of the PA-Client 389 message is AUTHENTICATION_SUCCEEDED. In addition, the PCP client 390 needs to update the PCP SA with the MSK and transport key, and uses 391 the derived transport key to secure the message. From then on, all 392 the PCP messages within the session are secured with the transport 393 key and the MAC algorithm specified in the PCP SA. The first secure 394 PA-client message from the client MUST include the set of PRF and 395 MAC_ALGORITHM options received from the PCP server. The PCP server 396 determines if the set of algorithms conveyed by the client matches 397 the set it had initially sent, to detect an algorithm downgrade 398 attack. If the server detects a downgrade attack then it MUST send a 399 PA-Server message with result code DOWNGRADE_ATTACK_DETECTED and 400 terminate the session. If the PCP client sends common PCP request 401 within the PA session without AUTHENTICATION_TAG option then the PCP 402 server rejects the request by returning AUTHENTICATION_REQUIRED error 403 code. 405 If a PCP client/server cannot authenticate its session partner, the 406 device sends out a PA message with the result code, 407 AUTHENTICATION_FAILED. If the EAP authentication succeeds but 408 authorization fails, the device making the decision sends out a PA 409 message with the result code, AUTHORIZATION_FAILED. In these two 410 cases, after the PA message is sent out, the PA session MUST be 411 terminated immediately. It is possible for independent PCP clients 412 on the host to create multiple PA sessions with the PCP server. 414 3.2. Recovery from lost PA session 416 If a PCP server resets or loses the PCP SA due to reboot, power 417 failure, or any reason then it sends unsolicited ANNOUNCE response as 418 explained in section 14.1.3 of [RFC6887] to the PCP client. Upon 419 receiving the ANNOUNCE response with an anomalous Epoch time, PCP 420 client deduces that the server may have lost state. The ANNOUNCE is 421 either bogus (an attack), legitimate, or not seen by the client. 422 These three cases are described below: 424 o PCP client sends integrity-protected unicast ANNOUNCE request to 425 the PCP server to check if the PCP server has indeed lost the 426 state or an attacker has sent the ANNOUNCE response. 428 * If integrity-protected success response is recevied from the 429 PCP server then the PCP client determines that the PCP server 430 has not lost the PA session, and the unsolicited ANNOUNCE 431 response was sent by an attacker. 433 * If the PCP server responds to the ANNOUNCE request with 434 UNKNOWN_SESSION_ID error code then the PCP client MUST initiate 435 full EAP authentication with the PCP server as explained in 436 Section 3.1.1. After EAP authentication is successful PCP 437 client updates the PCP SA and issues new common PCP requests to 438 recreate any lost mapping state. 440 o In a scenario where the PCP server has lost the PCP SA but did not 441 inform the PCP client, if the PCP client sends PCP request 442 integrity-protected then the PCP server rejects the request with 443 UNKNOWN_SESSION_ID error code. The PCP client then initiates full 444 EAP authentication with the PCP server as explained in 445 Section 3.1.1 and updates the PCP SA after successful 446 authentication. 448 If the PCP client resets or loses the PCP SA due to reboot, power 449 failure, or any reason and sends common PCP request then the PCP 450 server rejects the request with AUTHENTICATION_REQUIRED error code. 451 The PCP client MUST authenticate with the PCP server and after EAP 452 authentication is successful retry the common PCP request with 453 AUTHENTICATION_TAG option. The PCP server MUST update the PCP SA 454 after successful EAP authentication. 456 3.3. Session Termination 458 A PA session can be explicitly terminated by either session partner. 459 A PCP Server may explicitly request termination of the session by 460 sending an unsolicited termination-indicating PA response (a PA 461 response with a result code "SESSION-TERMINATED"). Upon receiving a 462 termination-indicating message, the PCP client MUST respond with a 463 termination-indicating PA message, and MUST then remove the 464 associated PCP SA. To accommodate packet loss, the PCP server MAY 465 transmit the termination-indicating PA response up to ten times (with 466 an appropriate Epoch Time value in each to reflect the passage of 467 time between transmissions) provided that the interval between the 468 first two notifications is at least 250 ms, and the interval between 469 subsequent notification at least doubles. 471 A PCP client may explicitly request termination of the session by 472 sending a termination-indicating PA request (a PA request with a 473 result code "SESSION-TERMINATED"). After receiving a termination- 474 indicating message from the PCP client, a PCP server MUST respond 475 with a termination-indicating PA response and remove the PCP SA 476 immediately. When the PCP client receives the termination-indicating 477 PA response, it MUST remove the associated PCP SA immediately. 479 3.4. Session Re-Authentication 481 A session partner may select to perform EAP re-authentication if it 482 would like to update the PCP SA without initiating a new PA session. 483 For example a re-authentication procedure could be triggered for the 484 following reasons: 486 o The session lifetime needs to be extended. 488 o The sequence number is going to reach the maximum value. 489 Specifically, when the sequence number reaches 2**32 - 2**16, the 490 session partner MUST trigger re-authentication. 492 When the PCP server would like to initiate a re-authentication, it 493 sends the PCP client a PA-Server message. The result code of the 494 message is set to "RE-AUTHENTICATION", which indicates the message is 495 for a re-authentication process. If the PCP client would like to 496 start the re-authentication, it will send a PA-Client message to the 497 PCP server, with the result code of the PA-Client message set to "RE- 498 AUTHENTICATION". Then, the session partners exchange PA messages to 499 transfer EAP messages for the re-authentication. During the re- 500 authentication procedure, the session partners protect the integrity 501 of PA messages with the key and MAC algorithm specified in the 502 current PCP SA; the sequence numbers associated with the message will 503 continue to keep increasing according to Section 6.3. The result 504 code for PA-Sever message carrying EAP request will be set to 505 AUTHENTICATION_REQUIRED and PA-Client message carrying EAP response 506 will be set to AUTHENTICATION_REPLY. 508 If the EAP re-authentication succeeds, the result code of the last 509 PA-Server message is "AUTHENTICATION_SUCCEEDED". In this case, 510 before sending out the PA-Server message, the PCP server MUST update 511 the SA and use the new key to generate a digest for the PA-Server 512 message and subsequent PCP messages. In addition, the PA-Server 513 message MUST be appended with a SESSION_LIFETIME Option which 514 indicates the new lifetime of the PA session. PA and PCP message 515 sequence numbers must also be reset to zero. 517 If the EAP authentication fails, the result code of the last PA- 518 Server message is "AUTHENTICATION_FAILED". If the EAP authentication 519 succeeds but authorization fails, the result code of the last PA- 520 Server message is "AUTHORIZATION_FAILED". In the latter two cases, 521 the PA session MUST be terminated immediately after the last PA 522 message exchange. If for some unknown reason re-authentication is 523 not performed and session lifetime has expired then PA session MUST 524 be terminated immediately. 526 During re-authentication, the session partners can also exchange 527 common PCP messages in parallel. The common PCP messages MUST be 528 protected with the current SA until the new SA has been generated. 529 The sequence of EAP messages exchanged for re-authentication will not 530 change, regardless of the PCP device triggering re-authentication. 531 If the PCP server receives re-authentication request from the PCP 532 client after it had signaled re-authentication request then it should 533 discard its request and respond to the re-authentication request from 534 the PCP client. 536 4. PA Security Association 538 At the beginning of a new PA session, each PCP device must create and 539 initialize state information for a new PA Security Association (PCP 540 SA) to maintain its state information for the duration of the PA 541 session. The parameters of a PCP SA are listed as follows: 543 o IP address and UDP port number of the PCP client 545 o IP address and UDP port number of the PCP server 547 o Session Identifier 549 o Sequence number for the next outgoing PA message 551 o Sequence number for the next incoming PA message 553 o Sequence number for the next outgoing common PCP message 555 o Sequence number for the next incoming common PCP message 557 o Last outgoing message payload 559 o Retransmission interval 561 o The master session key (MSK) generated by the EAP method. 563 o The MAC algorithm that the transport key should use to generate 564 digests for PCP messages. 566 o The pseudo random function negotiated in the initial PA-Server and 567 PA-Client message exchange for the transport key derivation 569 o The transport key derived from the MSK to provide integrity 570 protection and data origin authentication for the messages in the 571 PA session. The lifetime of the transport key SHOULD be identical 572 to the lifetime of the session. 574 o The nonce selected by the PCP client at the initiation of the 575 session. 577 o The Key ID associated with Transport key. 579 Particularly, the transport key is computed in the following way: 580 Transport key = prf(MSK, "IETF PCP" || Session ID || Nonce || key 581 ID), where: 583 o prf: The pseudo-random function assigned in the Pseudo-random 584 function parameter. 586 o MSK: The master session key generated by the EAP method. 588 o "IETF PCP": The ASCII code representation of the non-NULL 589 terminated string (excluding the double quotes around it). 591 o '||' : is the concatenation operator. 593 o Session ID: The ID of the session which the MSK is derived from. 595 o Nonce: The nonce selected by the client and transported in the 596 Initial PA-Client message. 598 o Key ID: The ID assigned for the transport key. 600 5. Packet Format 602 5.1. Packet Format of PCP Auth Messages 604 The format of the PA-Server message is identical to the response 605 message format specified in Section 7.2 of [RFC6887]. The result 606 code for PA-Sever message carrying EAP request MUST be set to 607 AUTHENTICATION_REQUEST. 609 As illustrated in Figure 1, this document updates the reserved field 610 in the request header specified in Section 7.1 of [RFC6887] to carry 611 Opcode-specific data. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Version = 2 |R| Opcode | Reserved |Opcode-specific| 617 | | | | | data | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Requested Lifetime (32 bits) | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | | 622 | PCP Client's IP Address (128 bits) | 623 | | 624 | | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 : : 627 : Opcode-specific information : 628 : : 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 : : 631 : (optional) PCP Options : 632 : : 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 Figure 1. Request Packet Format 637 As illustrated in Figure 2, the PA-Client messages use the request 638 header specified in Figure 1. The Opcode-specific data is used to 639 transfer the result codes (e.g., "INITIATION", 640 "AUTHENTICATION_FAILED"). Other fields in Figure 2 are described in 641 Section 7.1 of [RFC6887]. The result code for PA-Client message 642 carrying EAP response MUST be set to AUTHENTICATION_REPLY. 644 0 1 2 3 645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Version = 2 |R| Opcode | Reserved | Result Code | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Requested Lifetime (32 bits) | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | | 652 | PCP Client's IP Address (128 bits) | 653 | | 654 | | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 : : 657 : Opcode-specific information : 658 : : 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 : : 661 : (optional) PCP Options : 662 : : 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 Figure 2. PA-Client message Format 667 The Requested Lifetime field of PA-Client message and Lifetime field 668 of PA-Server message are both set to 0 on transmission and ignored on 669 reception. 671 5.2. Opcode-specific information of AUTHENTICATION Opcode 673 The following diagram shows the format of the Opcode-specific 674 information for the AUTHENTICATION Opcode. 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 | Session ID | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Sequence Number | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Session ID: This field contains a 32-bit PA session identifier. 686 Sequence Number: This field contains a 32-bit sequence number. A 687 sequence number needs to be incremented on every new (non- 688 retransmission) outgoing PA message in order to provide an 689 ordering guarantee for PA messages. 691 5.3. NONCE Option 693 Because the session identifier of a PA session is determined by the 694 PCP server, a PCP client does not know the session identifier which 695 will be used when it sends out a PA-Initiation message. In order to 696 prevent an attacker from interrupting the authentication process by 697 sending off-line generated PA-Server messages, the PCP client needs 698 to generate a random number as a nonce in the PA-Initiation message. 699 The PCP server will append the nonce within the initial PA-Server 700 message. If the PA-Server message does not carry the correct nonce, 701 the message MUST be discarded silently. 703 0 1 2 3 704 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 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Option Code | Reserved | Option-Length | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Nonce | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 Option Code: TBA-130. 713 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 714 ignored on reception. 716 Option-Length: 4 octets. 718 Nonce: A random 32 bit number which is transported within a PA- 719 Initiation message and the corresponding reply message from the 720 PCP server. 722 5.4. AUTHENTICATION_TAG Option 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Option Code | Reserved | Option-Length | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Session ID | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Sequence Number | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | Key ID | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | | 735 | Authentication Data (Variable) | 736 ~ ~ 737 | | 738 | | 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Because there is no authentication Opcode in common PCP messages, the 742 authentication tag for common PCP messages needs to carry the Session 743 ID and Sequence Number. 745 Option Code: TBA-131. 747 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 748 ignored on reception. 750 Option-Length: The length of the AUTHENTICATION_TAG Option for 751 Common PCP message (in octets), including the 12 octet fixed 752 header and the variable length of the authentication data. 754 Session ID: A 32-bit field used to identify the session to which 755 the message belongs and identify the secret key used to create the 756 message digest appended to the PCP message. 758 Sequence Number: A 32-bit sequence number. In this solution, a 759 sequence number needs to be incremented on every new (non- 760 retransmission) outgoing common PCP message in order to provide 761 ordering guarantee for common PCP messages. 763 Key ID: The ID associated with the transport key used to generate 764 authentication data. This field is filled with zero if the MSK is 765 directly used to secure the message. 767 Authentication Data: A variable-length field that carries the 768 Message Authentication Code for the Common PCP message. The 769 generation of the digest varies according to the algorithms 770 specified in different PCP SAs. This field MUST end on a 32-bit 771 boundary, padded with 0's when necessary. 773 5.5. PA_AUTHENTICATION_TAG option 775 This option is used to provide message authentication for PA 776 messages. Compared with the AUTHENTICATION_TAG Option for Common PCP 777 Messages, the Session ID field and the Sequence Number field are 778 removed because such information is provided in the Opcode-specific 779 information of AUTHENTICATION Opcode. 781 0 1 2 3 782 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 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | Option Code | Reserved | Option-Length | 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Key ID | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | | 789 | Authentication Data (Variable) | 790 ~ ~ 791 | | 792 | | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 Option Code: TBA-132. 797 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 798 ignored on reception. 800 Option-Length: The length of the PA_AUTHENTICATION Option for PCP 801 Auth message (in octet), including the 4 octet fixed header and 802 the variable length of the authentication data. 804 Key ID: The ID associated with the transport key used to generate 805 authentication data. This field is filled with zero if the MSK is 806 directly used to secure the message. 808 Authentication Data: A variable-length field that carries the 809 Message Authentication Code for the PCP Auth message. The 810 generation of the digest varies according to the algorithms 811 specified in different PCP SAs. This field MUST end on a 32-bit 812 boundary, padded with null characters when necessary. 814 5.6. EAP_PAYLOAD Option 816 0 1 2 3 817 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 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Option Code | Reserved | Option-Length | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | | 822 | EAP Message | 823 ~ ~ 824 | | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 Option Code: TBA-133. 829 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 830 ignored on reception. 832 Option-Length: Variable 834 EAP Message: The EAP message transferred. Note this field MUST 835 end on a 32-bit boundary, padded with 0's when necessary. 837 5.7. PRF Option 839 0 1 2 3 840 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 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | Option Code | Reserved | Option-Length | 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | PRF | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 Option Code: TBA-134. 849 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 850 ignored on reception. 852 Option-Length: 4 octets. 854 PRF: The Pseudo-Random Function which the sender supports to generate 855 an MSK. This field contains an IKEv2 Transform ID of Transform Type 856 2 [RFC7296][RFC4868]. A PCP implementation MUST support 857 PRF_HMAC_SHA2_256 (5). 859 5.8. MAC_ALGORITHM Option 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Option Code | Reserved | Option-Length | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | MAC Algorithm ID | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 Option Code: TBA-135. 871 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 872 ignored on reception. 874 Option-Length: 4 octets. 876 MAC Algorithm ID: Indicate the MAC algorithm which the sender 877 supports to generate authentication data. The MAC Algorithm ID field 878 contains an IKEv2 Transform ID of Transform Type 3 879 [RFC7296][RFC4868]. A PCP implementation MUST support 880 AUTH_HMAC_SHA2_256_128 (12). 882 5.9. SESSION_LIFETIME Option 884 0 1 2 3 885 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 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Option Code | Reserved | Option-Length | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Session Lifetime | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 Option Code: TBA-136. 894 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 895 ignored on reception. 897 Option-Length: 4 octets. 899 Session Lifetime: An unsigned 32-bit integer, in seconds, ranging 900 from 0 to 2^32-1 seconds. The lifetime of the PA Session, which is 901 decided by the authorization result. 903 5.10. RECEIVED_PAK Option 905 This option is used in a PA-Acknowledgement message to indicate that 906 a PA message with the contained sequence number has been received. 908 0 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Option Code | Reserved | Option-Length | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | Received Sequence Number | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 Option Code: TBA-137. 918 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 919 ignored on reception. 921 Option-Length: 4 octets. 923 Received Sequence Number: The sequence number of the last received PA 924 message. 926 5.11. ID_INDICATOR Option 928 The ID_INDICATOR option is used by the PCP client to determine which 929 credentials to provide to the PCP server. 931 0 1 2 3 932 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 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Option Code | Reserved | Option-Length | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | | 937 | ID Indicator | 938 ~ ~ 939 | | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 Option Code: TBA-138. 944 Reserved: 8 bits. MUST be set to 0 on transmission and MUST be 945 ignored on reception. 947 Option-Length: Variable. 949 ID Indicator: The identity of the authority that issued the EAP 950 credentials to be used to authenticate the client. The field MUST 951 NOT be null terminated and its length is indicated by the Option- 952 Length field. In particular when a client receives a ID_INDICATOR 953 option, it MUST NOT rely on the presence of a NUL character in the 954 wire format data to identify the end of the ID Indicator field. 956 The field MUST end on a 32-bit boundary, padded with 0's when 957 necessary. The ID indicator field is UTF-8 encoded [RFC3629] 958 Unicode string conforming to the "UsernameCaseMapped" profile of 959 the PRECIS IdentifierClass [I-D.ietf-precis-saslprepbis]. The PCP 960 client validates that the ID indicator field conforms to the 961 "UsernameCaseMapped" profile of the PRECIS IdentifierClass. The 962 PCP client enforces the rules specified in section 3.2.2 of 963 [I-D.ietf-precis-saslprepbis] to map the ID indicator field. The 964 PCP client compares the resulting string with the ID indicators 965 stored locally on the PCP client to pick the credentials for 966 authentication. The two indicator strings are to be considered 967 equivalent by the client if and only if they are an exact octet- 968 for-octet match. 970 6. Processing Rules 972 6.1. Authentication Data Generation 974 After successful EAP authentication process, every subsequent PCP 975 message within the PA session MUST carry an authentication tag which 976 contains the digest of the PCP message for data origin authentication 977 and integrity protection. 979 o Before generating a digest for a PA message, a device needs to 980 first locate the PCP SA according to the session identifier and 981 then get the transport key. Then the device appends an 982 PA_AUTHENTICATION_TAG Option for PCP Auth at the end of the PCP 983 Auth message. The length of the Authentication Data field is 984 decided by the MAC algorithm adopted in the session. The device 985 then fills the Key ID field with the key ID of the transport key, 986 and sets the Authentication Data field to 0. After this, the 987 device generates a digest for the entire PCP message (including 988 the PCP header and PA_AUTHENTICATION_TAG Option) using the 989 transport key and the associated MAC algorithm, and inserts the 990 generated digest into the Authentication Data field. 992 o Similar to generating a digest for a PA message, before generating 993 a digest for a common PCP message, a device needs to first locate 994 the PCP SA according to the session identifier and then get the 995 transport key. Then the device appends the AUTHENTICATION_TAG 996 Option at the end of common PCP message. The length of the 997 Authentication Data field is decided by the MAC algorithm adopted 998 in the session. The device then uses the corresponding values 999 derived from the SA to fill the Session ID field, the Sequence 1000 Number field and the Key ID field, and sets the Authentication 1001 Data field to 0. After this, the device generates a digest for 1002 the entire PCP message (including the PCP header and 1003 AUTHENTICATION_TAG Option) using the transport key and the 1004 associated MAC algorithm, and inputs the generated digest into the 1005 Authentication Data field. 1007 6.2. Authentication Data Validation 1009 When a device receives a common PCP message with an 1010 AUTHENTICATION_TAG Option for Common PCP Messages, the device needs 1011 to use the Session ID transported in the option to locate the proper 1012 SA, and then find the associated transport key (using the key ID in 1013 the option) and the MAC algorithm. If no proper SA or transport key 1014 is found or the sequence number is invalid (see Section 6.5), the PCP 1015 device stops processing the PCP message and discards the message 1016 silently. After storing the value of the Authentication field of the 1017 AUTHENTICATION_TAG Option, the device fills the Authentication field 1018 with zeros. Then, the device generates a digest for the message 1019 (including the PCP header and Authentication Tag Option) with the 1020 transport key and the MAC algorithm. If the value of the newly 1021 generated digest is identical to the stored one, the device can 1022 ensure that the message has not been tampered with, and the 1023 validation succeeds. Otherwise, the PCP device stops processing the 1024 PCP message and silently discards the message. 1026 Similarly, when a device receives a PA message with an 1027 PA_AUTHENTICATION_TAG Option for PCP Authentication, the device needs 1028 to use the Session ID transported in the Opcode to locate the proper 1029 SA, and then find the associated transport key (using the key ID in 1030 the option) and the MAC algorithm. If no proper SA or transport key 1031 is found or the sequence number is invalid (see Section 6.4), the PCP 1032 device stops processing the PCP message and discards the message. 1033 After storing the value of the Authentication field of the 1034 PA_AUTHENTICATION_TAG Option, the device fills the Authentication 1035 field with zeros. Then, the device generates a digest for the 1036 message (including the PCP header and PA_AUTHENTICATION_TAG Option) 1037 with the transport key and the MAC algorithm. If the value of the 1038 newly generated digest is identical to the stored one, the device can 1039 ensure that the message has not been tampered with, and the 1040 validation succeeds. Otherwise, the PCP device stops processing the 1041 PCP message and silently discards the message. 1043 6.3. Retransmission Policies for PA Messages 1045 Because EAP relies on the underlying protocols to provide reliable 1046 transmission, after sending a PA message, a PCP client/server MUST 1047 NOT send out any subsequent messages until receiving a PA message 1048 with a proper sequence number from the peer. If no such a message is 1049 received the PCP device will re-send the last message according to 1050 retransmission policies. This work reuses the retransmission 1051 policies specified in the base PCP protocol (Section 8.1.1 of 1052 [RFC6887]). In the base PCP protocol, such retransmission policies 1053 are only applied by PCP clients. However, in this work, such 1054 retransmission policies are also applied by the PCP servers. If 1055 Maximum retransmission duration seconds have elapsed and no expected 1056 response is received, the device will terminate the session and 1057 discard the current SA. 1059 As illustrated in Section 3.1.3, in order to avoid unnecessary re- 1060 transmission, the device receiving a PA message MUST send a PA- 1061 Acknowledgement message to the sender of the PA message when it 1062 cannot send a PA response immediately. The PA-Acknowledgement 1063 message is used to indicate the receipt of the PA message. When the 1064 sender receives the PA-Acknowledgement message, it will stop the 1065 retransmission. 1067 Note that the last PA messages transported within the phases of 1068 session initiation, session re-authentication, and session 1069 termination do not have to follow the above policies since the 1070 devices sending out those messages do not expect any further PA 1071 messages. 1073 When a device receives a re-transmitted last incoming PA message from 1074 its session partner, it MUST try to answer it by sending the last 1075 outgoing PA message again. However, if the duplicate message has the 1076 same sequence number but is not bit-wise identical to the original 1077 message then the device MUST discard it. In order to achieve this 1078 function, the device may need to maintain the last incoming and the 1079 associated outgoing messages. In this case, if no outgoing PA 1080 message has been generated for the received duplicate PA message yet, 1081 the device needs to send a PA-Acknowledgement message. The rate of 1082 replying to duplicate PA messages MUST be limited to provide 1083 robustness against denial of service (DoS) attacks. The details of 1084 rate limiting are outside the scope of this specification. 1086 6.4. Sequence Numbers for PCP Auth Messages 1088 PCP uses UDP to transport signaling messages. As an un-reliable 1089 transport protocol, UDP does not guarantee ordered packet delivery 1090 and does not provide any protection from packet loss. In order to 1091 ensure the EAP messages are exchanged in a reliable way, every PCP 1092 message exchanged during EAP authentication must carry a 1093 monotonically increasing sequence number. During a PA session, a PCP 1094 device needs to maintain two sequence numbers for PA messages, one 1095 for incoming PA messages and one for outgoing PA messages. When 1096 generating an outgoing PA message, the device adds the associated 1097 outgoing sequence number to the message and increments the sequence 1098 number maintained in the SA by 1. When receiving a PA message from 1099 its session partner, the device will not accept it if the sequence 1100 number carried in the message does not match the incoming sequence 1101 number the device maintains. After confirming that the received 1102 message is valid, the device increments the incoming sequence number 1103 maintained in the SA by 1. 1105 The above rules are not applicable to PA-Acknowledgement messages 1106 (i.e., PA messages containing a RECEIVED_PAK Option). A PA- 1107 Acknowledgement message does not transport any EAP message and only 1108 indicates that a PA message is received. Therefore, reliable 1109 transmission of PA-Acknowledgement messages is not required. For 1110 instance, after sending out a PA-Acknowledgement message, a device 1111 generates an EAP response. In this case, the device need not have to 1112 confirm whether the PA-Acknowledgement message has been received by 1113 its session partner or not. Therefore, when receiving or sending out 1114 a PA-Acknowledgement message, the device MUST NOT increase the 1115 corresponding sequence number stored in the SA. Otherwise, loss of a 1116 PA-Acknowledgement message will cause a mismatch in sequence numbers. 1118 Another exception is the message retransmission scenario. As 1119 discussed in Section 6.3, when a PCP device does not receive any 1120 response from its session partner it needs to retransmit the last 1121 outgoing PA message following the retransmission procedure specified 1122 in section 8.1.1 of [RFC6887]. The original message and duplicate 1123 messages MUST be bit-wise identical. When the device receives such a 1124 duplicate PA message from its session partner, it MUST send the last 1125 outgoing PA message again. In such cases, the maintained incoming 1126 and outgoing sequence numbers will not be affected by the message 1127 retransmission. 1129 6.5. Sequence Numbers for Common PCP Messages 1131 When transporting common PCP messages within a PA session, a PCP 1132 device needs to maintain a sequence number for outgoing common PCP 1133 messages and a sequence number for incoming common PCP messages. 1134 When generating a new outgoing PCP message, the PCP device updates 1135 the Sequence Number field in the AUTHENTICATION_TAG option with the 1136 outgoing sequence number maintained in the SA and increments the 1137 outgoing sequence number by 1. 1139 When receiving a PCP message from its session partner, the PCP device 1140 will not accept it if the sequence number carried in the message is 1141 smaller than the incoming sequence number the device maintains. This 1142 approach can protect the PCP device from replay attacks. After 1143 confirming that the received message is valid, the PCP device will 1144 update the incoming sequence number maintained in the PCP SA with the 1145 sequence number of the incoming message. 1147 Note that the sequence number in the incoming message may not exactly 1148 match the incoming sequence number maintained locally. As discussed 1149 in the base PCP specification [RFC6887], if a PCP client is no longer 1150 interested in the PCP transaction and has not yet received a PCP 1151 response from the server then it will stop retransmitting the PCP 1152 request. After that, the PCP client might generate new PCP requests 1153 for other purposes using the current SA. In this case, the sequence 1154 number in the new request will be larger than the sequence number in 1155 the old request and so will be larger than the incoming sequence 1156 number maintained in the PCP server. 1158 Note that in the base PCP specification [RFC6887], a PCP client needs 1159 to select a nonce in each MAP or PEER request, and the nonce is sent 1160 back in the response. However, it is possible for a client to use 1161 the same nonce in multiple MAP or PEER requests, and this may cause a 1162 potential risk of replay attacks. This attack is addressed by using 1163 the sequence number in the PCP response. 1165 6.6. MTU Considerations 1167 EAP methods are responsible for MTU handling, so no special 1168 facilities are required in PCP to deal with MTU issues. 1169 Particularly, EAP lower layers indicate to EAP methods and AAA 1170 servers the MTU of the lower layer. EAP methods such as EAP-TLS 1171 [RFC5216], TEAP [RFC7170], and others that are likely to exceed 1172 reasonable MTUs provide support for fragmentation and reassembly. 1173 Others, such as EAP-GPSK [RFC5433] assume they will never send 1174 packets larger than the MTU and use small EAP packets. 1176 If an EAP message is too long to be transported within a single PA 1177 message, it will be divided into multiple sections and sent within 1178 different PA messages. Note that the receiver may not be able to 1179 know what to do in the next step until it has received all the 1180 sections and reconstructed the complete EAP message. In this case, 1181 in order to guarantee reliable message transmission, after receiving 1182 a PA message, the receiver replies with a PA-Acknowledgement message 1183 to notify the sender to send the next PA message. 1185 7. IANA Considerations 1187 The following PCP Opcode is to be allocated in the mandatory-to- 1188 process range from the standards action range (the registry for PCP 1189 Opcodes is maintained in http://www.iana.org/assignments/pcp- 1190 parameters): 1192 TBA AUTHENTICATION Opcode. 1194 The following PCP result codes are to be allocated in the mandatory- 1195 to-process range from the standards action range (the registry for 1196 PCP result codes is maintained in http://www.iana.org/assignments/ 1197 pcp-parameters): 1199 TBA INITIATION: The client indication to the server for 1200 authentication. 1202 TBA AUTHENTICATION_REQUIRED: The error response is signaled to the 1203 client that EAP authentication is required. 1205 TBA AUTHENTICATION_FAILED: This error response is signaled to the 1206 client if EAP authentication had failed. 1208 TBA AUTHENTICATION_SUCCEEDED:This success response is signaled to 1209 the client if EAP authentication had succeeded. 1211 TBA AUTHORIZATION_FAILED: This error response is signaled to the 1212 client if the EAP authentication had succeeded but authorization 1213 failed. 1215 TBA SESSION_TERMINATED: This PCP result code indicates to the 1216 partner that the PA session must be terminated. 1218 TBA UNKNOWN_SESSION_ID: The error response is signaled from the 1219 PCP server that there is no known PA session associated with the 1220 Session ID signaled in the PA request or common PCP request from 1221 the PCP client. 1223 TBA DOWNGRADE_ATTACK_DETECTED: This error response is signaled to 1224 the client if the server detects downgrade attack. 1226 TBA AUTHENTICATION_REQUEST: The server indication to the client 1227 that EAP request is signaled in the PA message. 1229 TBA AUTHENTICATION_REPLY: The client indication to the server that 1230 EAP response is signaled in the PA message. 1232 The following PCP Option Codes are to be allocated in the mandatory- 1233 to-process range from the standards action range (the registry for 1234 PCP Options is maintained in http://www.iana.org/assignments/pcp- 1235 parameters): 1237 7.1. NONCE 1239 Option Name: NONCE 1241 option-code: TBA-130 in the mandatory-to-process range (IANA). 1243 Purpose: See Section 5.3. 1245 Valid for Opcodes: Authentication Opcode. 1247 option-len: Option Length is 4 octets. 1249 May appear in: request and response. 1251 Maximum occurrences: 1. 1253 7.2. AUTHENTICATION_TAG 1255 Option Name: AUTHENTICATION_TAG 1257 option-code: TBA-131 in the mandatory-to-process range (IANA). 1259 Purpose: See Section 5.4. 1261 Valid for Opcodes: MAP, PEER and ANNOUNCE Opcodes. 1263 option-len: Variable length. 1265 May appear in: request and response. 1267 Maximum occurrences: 1. 1269 7.3. PA_AUTHENTICATION_TAG 1271 Option Name: PA_AUTHENTICATION_TAG 1273 option-code: TBA-132 in the mandatory-to-process range (IANA). 1275 Purpose: See Section 5.5. 1277 Valid for Opcodes: Authentication Opcode. 1279 option-len: Variable length. 1281 May appear in: request and response. 1283 Maximum occurrences: 1. 1285 7.4. EAP_PAYLOAD 1287 Option Name: EAP_PAYLOAD. 1289 option-code: TBA-133 in the mandatory-to-process range (IANA). 1291 Purpose: See Section 5.6. 1293 Valid for Opcodes: Authentication Opcode. 1295 option-len: Variable length. 1297 May appear in: request and response. 1299 Maximum occurrences: 1. 1301 7.5. PRF 1303 Option Name: PRF. 1305 option-code: TBA-134 in the mandatory-to-process range (IANA). 1307 Purpose: See Section 5.7. 1309 Valid for Opcodes: Authentication Opcode. 1311 option-len: Option Length is 4 octets. 1313 May appear in: request and response. 1315 Maximum occurrences: as many as fit within maximum PCP message size. 1317 7.6. MAC_ALGORITHM 1319 Option Name: MAC_ALGORITHM. 1321 option-code: TBA-135 in the mandatory-to-process range (IANA). 1323 Purpose: See Section 5.8. 1325 Valid for Opcodes: Authentication Opcode. 1327 option-len: Option Length is 4 octets. 1329 May appear in: request and response. 1331 Maximum occurrences: as many as fit within maximum PCP message size. 1333 7.7. SESSION_LIFETIME 1335 Option Name: SESSION_LIFETIME. 1337 option-code: TBA-136 in the mandatory-to-process range (IANA). 1339 Purpose: See Section 5.9. 1341 Valid for Opcodes: Authentication Opcode. 1343 option-len: Option Length is 4 octets. 1345 May appear in: response. 1347 Maximum occurrences: 1. 1349 7.8. RECEIVED_PAK 1351 Option Name: RECEIVED_PAK. 1353 option-code: TBA-137 in the mandatory-to-process range (IANA). 1355 Purpose: See Section 5.10. 1357 Valid for Opcodes: Authentication Opcode. 1359 option-len: Option Length is 4 octets. 1361 May appear in: request and response. 1363 Maximum occurrences: 1. 1365 7.9. ID_INDICATOR 1367 Option Name: ID_INDICATOR. 1369 option-code: TBA-138 in the mandatory-to-process range (IANA). 1371 Purpose: See Section 5.11. 1373 Valid for Opcodes: Authentication Opcode. 1375 option-len: Variable length. 1377 May appear in: response. 1379 Maximum occurrences: 1. 1381 8. Security Considerations 1383 In this work, after a successful EAP authentication process is 1384 performed between two PCP devices, an MSK will be exported. The MSK 1385 will be used to derive the transport keys to generate MAC digests for 1386 subsequent PCP message exchanges. However, before a transport key 1387 has been generated, the PA messages exchanged within a PA session 1388 have little cryptographic protection, and if there is no already 1389 established security channel between two session partners, these 1390 messages are subject to man-in-the-middle attacks and DOS attacks. 1391 For instance, the initial PA-Server and PA-Client message exchange is 1392 vulnerable to spoofing attacks as these messages are not 1393 authenticated and integrity protected. In addition, because the PRF 1394 and MAC algorithms are transported at this stage, an attacker may try 1395 to remove the PRF and MAC options containing strong algorithms from 1396 the initial PA-Server message and force the client choose the weakest 1397 algorithms. Therefore, the server needs to guarantee that all the 1398 PRF and MAC algorithms it provides support for are strong enough. 1400 In order to prevent very basic DOS attacks, a PCP device SHOULD 1401 generate state information as little as possible in the initial PA- 1402 Server and PA-Client message exchanges. The choice of EAP method is 1403 also very important. The selected EAP method must be resilient to 1404 the attacks possible in an insecure network environment, provide 1405 user-identity confidentiality, protection against dictionary attacks, 1406 and support session-key establishment. 1408 When a PCP proxy [I-D.ietf-pcp-proxy] is located between a PCP server 1409 and PCP clients, the proxy may perform authentication with the PCP 1410 server before it processes requests from the clients. In addition, 1411 re-authentication between the PCP proxy and PCP server will not 1412 interrupt the service that the proxy provides to the clients since 1413 the proxy is still allowed to send common PCP messages to the PCP 1414 server during that period. 1416 9. Acknowledgements 1418 Thanks to Dan Wing, Prashanth Patil, Dave Thaler, Peter Saint-Andre, 1419 Carlos Pignataro, Brian Haberman, Paul Kyzivat, Jouni Korhonen, 1420 Stephen Farrell and Terry Manderson for the valuable comments. 1422 10. Change Log 1424 [Note: This section should be removed by the RFC Editor upon 1425 publication] 1427 10.1. Changes from wasserman-pcp-authentication-02 to ietf-pcp- 1428 authentication-00 1430 o Added discussion of in-band and out-of-band key management 1431 options, leaving choice open for later WG decision. 1433 o Removed support for fragmenting EAP messages, as that is handled 1434 by EAP methods. 1436 10.2. Changes from wasserman-pcp-authentication-01 to -02 1438 o Add a nonce into the first two exchanged PCP-Auth message between 1439 the PCP client and PCP server. When a PCP client initiate the 1440 session, it can use the nonce to detect offline attacks. 1442 o Add the key ID field into the authentication tag option so that a 1443 MSK can generate multiple transport keys. 1445 o Specify that when a PCP device receives a PCP-Auth-Server or a 1446 PCP-Auth-Client message from its partner the PCP device needs to 1447 reply with a PCP-Auth-Acknowledge message to indicate that the 1448 message has been received. 1450 o Add the support of fragmenting EAP messages. 1452 10.3. Changes from ietf-pcp-authentication-00 to -01 1454 o Editorial changes, added use cases to introduction. 1456 10.4. Changes from ietf-pcp-authentication-01 to -02 1458 o Add the support of re-authentication initiated by PCP server. 1460 o Specify that when a PCP device receives a PCP-Auth-Server or a 1461 PCP-Auth-Client message from its partner the PCP device MAY reply 1462 with a PCP-Auth-Acknowledge message to indicate that the message 1463 has been received. 1465 o Discuss the format of the PCP-Auth-Acknowledge message. 1467 o Remove the redundant information from the Auth Opcode, and specify 1468 new result codes transported in PCP packet headers 1470 o 1472 10.5. Changes from ietf-pcp-authentication-02 to -03 1474 o Change the name "PCP-Auth-Request" to "PCP-Auth-Server" 1476 o Change the name "PCP-Auth-Response" to "PCP-Auth-Client" 1478 o Specify two new sequence numbers for common PCP messages in the 1479 PCP SA, and describe how to use them 1481 o Specify a Authentication Tag Option for PCP Common Messages 1483 o Introduce the scenario where a EAP message has to be divided into 1484 multiple sections and transported in different PCP-Auth messages 1485 (for the reasons of MTU), and introduce how to use PCP-Auth- 1486 Acknowledge messages to ensure reliable packet delivery in this 1487 case. 1489 10.6. Changes from ietf-pcp-authentication-03 to -04 1491 o Change the name "PCP-Auth" to "PA". 1493 o Refine the retransmission policies. 1495 o Add more discussion about the sequence number management . 1497 o Provide the discussion about how to instruct a PCP client to 1498 choose proper credential during authentication, and an ID 1499 Indicator Option is defined for that purpose. 1501 10.7. Changes from ietf-pcp-authentication-04 to -05 1503 o Add contents in IANA considerations. 1505 o Add discussions in fragmentation. 1507 o Refine the PA messages retransmission policies. 1509 o Add IANA considerations. 1511 10.8. Changes from ietf-pcp-authentication-05 to -06 1513 o Added mechanism to handle algorithm downgrade attack. 1515 o Updated Security Considerations section. 1517 o Updated ID Indicator Option. 1519 11. References 1521 11.1. Normative References 1523 [I-D.ietf-pcp-proxy] 1524 Perreault, S., Boucadair, M., Penno, R., Wing, D., and S. 1525 Cheshire, "Port Control Protocol (PCP) Proxy Function", 1526 draft-ietf-pcp-proxy-09 (work in progress), July 2015. 1528 [I-D.ietf-precis-saslprepbis] 1529 Saint-Andre, P. and A. Melnikov, "Preparation, 1530 Enforcement, and Comparison of Internationalized Strings 1531 Representing Usernames and Passwords", draft-ietf-precis- 1532 saslprepbis-18 (work in progress), May 2015. 1534 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1535 Requirement Levels", BCP 14, RFC 2119, 1536 DOI 10.17487/RFC2119, March 1997, 1537 . 1539 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1540 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 1541 2003, . 1543 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1544 Levkowetz, Ed., "Extensible Authentication Protocol 1545 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1546 . 1548 [RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA- 1549 384, and HMAC-SHA-512 with IPsec", RFC 4868, 1550 DOI 10.17487/RFC4868, May 2007, 1551 . 1553 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 1554 Protocol Tunneled Transport Layer Security Authenticated 1555 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, 1556 DOI 10.17487/RFC5281, August 2008, 1557 . 1559 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 1560 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 1561 DOI 10.17487/RFC6887, April 2013, 1562 . 1564 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1565 "Tunnel Extensible Authentication Protocol (TEAP) Version 1566 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1567 . 1569 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1570 Kivinen, "Internet Key Exchange Protocol Version 2 1571 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1572 2014, . 1574 11.2. Informative References 1576 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 1577 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 1578 March 2008, . 1580 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 1581 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 1582 RFC 5433, DOI 10.17487/RFC5433, February 2009, 1583 . 1585 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1586 Extensible Authentication Protocol Method for 3rd 1587 Generation Authentication and Key Agreement (EAP-AKA')", 1588 RFC 5448, DOI 10.17487/RFC5448, May 2009, 1589 . 1591 Authors' Addresses 1593 Margaret Wasserman 1594 Painless Security 1595 356 Abbott Street 1596 North Andover, MA 01845 1597 USA 1599 Phone: +1 781 405 7464 1600 Email: mrw@painless-security.com 1601 URI: http://www.painless-security.com 1603 Sam Hartman 1604 Painless Security 1605 356 Abbott Street 1606 North Andover, MA 01845 1607 USA 1609 Email: hartmans@painless-security.com 1610 URI: http://www.painless-security.com 1611 Dacheng Zhang 1612 Huawei 1613 Beijing 1614 China 1616 Email: zhang_dacheng@hotmail.com 1618 Tirumaleswar Reddy 1619 Cisco Systems, Inc. 1620 Cessna Business Park, Varthur Hobli 1621 Sarjapur Marathalli Outer Ring Road 1622 Bangalore, Karnataka 560103 1623 India 1625 Email: tireddy@cisco.com