idnits 2.17.1 draft-reddy-pcp-auth-req-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 16, 2013) is 3998 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 4949 == Outdated reference: A later version (-09) exists of draft-ietf-pcp-proxy-02 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCP Working Group T. Reddy 3 Internet-Draft P. Patil 4 Intended status: Standards Track D. Wing 5 Expires: November 17, 2013 R. Penno 6 Cisco 7 May 16, 2013 9 PCP Authentication Requirements 10 draft-reddy-pcp-auth-req-03 12 Abstract 14 In an attempt to reach consensus on a PCP authentication mechanism, 15 this document describes requirements for PCP authentication. It is 16 hoped this can serve as the basis for a comparison of PCP 17 authentication mechanisms. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 17, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 2 56 4. Third Party Authorization . . . . . . . . . . . . . . . . . . 5 57 5. Other recommendations . . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 62 8.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 8 64 A.1. Change from -01 to -02 . . . . . . . . . . . . . . . . . 8 65 A.2. Change from -02 to -03 . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 This document derives requirements for PCP Authentication from PCP 71 deployment scenarios and scope described in PCP-base 72 [I-D.ietf-pcp-base] and other PCP drafts. The document focuses on 73 requirements and does not make a suggestion on the authentication 74 mechanism to be used to satisfy requirements. 76 2. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 This note uses terminologies defined in [RFC4949] such as realm, 83 security association, identity, credential etc. 85 3. Requirements 87 REQ-1: PCP MUST provide client authentication. PCP client and 88 server MUST also be able to mutually authenticate. Mutual 89 authentication is especially necessary when the PCP server is 90 located in a different administrative domain from the PCP client. 91 Credentials to gain access to the network could be different from 92 the credentials used to authenticate with the PCP server. 94 * The identity details of the client could be used by the PCP 95 server to grant access to certain PCP opcodes or PCP options. 96 For example GUESTS might not be permitted to use the MAP opcode 97 and only ADMINISTRATOR might be permitted to use the 98 THIRD_PARTY option. 100 * The identity details of the client could be used for auditing. 102 REQ-2: PCP Authentication MUST generate security association for 103 integrity protection of PCP request and response. This and all 104 subsequent requirements are not applicable to multicast PCP 105 responses like ANNOUNCE. 107 REQ-3: A PCP server MUST be able to indicate that a request will not 108 be processed without authentication. 110 REQ-4: If a PCP client authenticates with a PCP server, 112 a. The client MUST be able to verify the integrity and origin of 113 responses from the server. 115 b. The server MUST be able to send authenticated unsolicited 116 responses. 118 c. If a PCP response does not include integrity related to a 119 current security association, then those messages MUST NOT be 120 trusted without soliciting an integrity protected version. 122 d. If the server wants to send an unsolicited message, but the 123 previous security association association for the mapping 124 identified in the original PCP request has expired 126 1. The server can continue to use the same SA to protect 127 messages pertaining to that mapping, even if the SA is 128 technically expired. 130 - Such server notifications will not change state in the 131 PCP client. 133 - The notification could be a trigger for the client to 134 re-authenticate. For example, if the server indicates 135 that external IP address/port has changed, the PCP 136 client can then re-authenticate with the server to 137 confirm if the external IP address/port for the mapping 138 has indeed changed. 140 2. The server MUST be able to optionally trigger re- 141 authentication with the client. 143 REQ-5: It is important that PCP not leak privacy information between 144 the PCP client and PCP server, 146 a. The authentication mechanism MUST be able to keep credentials 147 hidden from eavesdroppers on path between the client and 148 server. 150 b. Confidentiality of the PCP messages is OPTIONAL for PCP 151 request and response of opcodes MAP, PEER, ANNOUNCE and 152 options THIRD_PARTY, PREFER_FAILURE and FILTER as explained in 153 PCP-base [I-D.ietf-pcp-base]. Other PCP drafts MUST evaluate 154 if confidentiality is OPTIONAL for new PCP opcodes and options 155 introduced. 157 c. PCP authentication SHOULD be immune to passive dictionary 158 attacks. 160 d. PCP Authentication MUST ensure that an attacker snooping PCP 161 messages cannot guess the SA. 163 REQ-6: To ease troubleshooting and ensure fate sharing, PCP 164 authentication and PCP messages MUST be multiplexed over the same 165 port. 167 REQ-7: PCP authentication MUST accommodate authentication between 168 administrative domains. For example, a PCP client may wish to 169 communicate directly to an ISP's PCP server, even though the in- 170 home CPE router does not support PCP. In this scenario the PCP 171 client needs to directly authenticate with the ISP's PCP server. 173 REQ-8: For the scenarios described in REQ-7, the PCP authentication 174 mechanism MUST be functional across address and port translation, 175 including NAPT64 and NAPT44. 177 REQ-9: A PCP proxy that modifies PCP requests and/or responses 178 before forwarding messages: 180 +------------+ | 181 | PCP Client |-----+ | 182 +--(Host 1)--+ | +-----------+ | +----------+ 183 +---| | | | | 184 | PCP Proxy |-------|PCP Server| 186 +---| | | | | 187 +------------+ | +-----------+ | +----------+ 188 | PCP Client |-----+ | 189 +--(Host 2)--+ possible boundary 190 <- Home side | ISP side -> 192 a. MUST be able to validate message integrity of PCP messages 193 from the PCP server and client respectively. 195 b. MUST be able to ensure message integrity after updating the 196 PCP message for cases described in sections 6 and 7 of 197 [I-D.ietf-pcp-proxy]. 199 REQ-10: It is RECOMMENDED that PCP authentication support a 200 mechanism where authentication on one port MUST be usable on other 201 ports without requiring another authentication exchange for other 202 ports. For example, there could multiple applications on the host 203 like BitTorrent [BitTorrent], WebRTC[I-D.ietf-rtcweb-overview]/SIP 204 [RFC3261] using PCP. Multiple authentication exchanges increase 205 load on the PCP server and chatter on the network. For example, 206 if 'N' messages are to be exchanged for PCP authentication and 'M' 207 independent applications implement their own PCP client, a total 208 of N*M messages have to be exchanged and 'M' number of SAs 209 maintained for each host. 211 REQ-11: It is RECOMMENDED to choose a widely deployed authentication 212 technique with known security properties rather than inventing a 213 new authentication mechanism. 215 REQ-12: Changes in PCP to accommodate authentication SHOULD be 216 minimal so that updates and additions to the authentication 217 mechanism have minimal bearing on modifying PCP. 219 4. Third Party Authorization 221 REQ-13: In addition to a two party authentication that has been 222 discussed in this draft, a mechanism for third party authorization 223 MUST also be supported. This is applicable in cases where a third 224 party authorizes the use of a resource on a PCP server for a desired 225 PCP client. For example, as depicted in Figure 1 , a PCP request to 226 a PCP capable firewall authorized by a SIP proxy rather than by 227 virtue of the end user making the PCP request. The PCP server is to 228 permit a PCP MAP request from the PCP client if the user is making a 229 SIP call with the Enterprise or a trusted SIP server in 3rd party 230 network, otherwise do not allow MAP request from that particular 231 user. In this scenario the first party is the user, second party is 232 the PCP server (which is also the firewall) and the third party is 233 the SIP server, where the user is authorized to use MAP request only 234 when making a call using the trusted SIP Server. 236 ========================= 237 | SIP Server | 238 ========================= 239 | 3rd Party Network 240 | 241 | 242 ================== 243 | WAN |-----+-+----+---+----+-+--- 244 ================== | 245 | | 246 | | 247 | | 248 +-------+-------+ | 249 | Firewall - | | 250 | PCP Server | | 251 +-------+-------+ | 252 | | 253 | | 254 Network A | | Network B 255 -+-+-----+-----------+-+-----+-------- -----+-+-------+------ 256 | | 257 +-+------+ +--------+ 258 | Alice | | Bob | 259 +--------+ +--------+ 261 Users : Alice, Bob 263 Figure 1: WebRTC server in a different administrative domain 265 5. Other recommendations 267 REQ-14: There SHOULD be support for a means to provide integrity 268 protection without user authentication, i.e., integrity protection 269 for PCP messages exchanged between a PCP server and anonymous PCP 270 clients. For example, a client visiting foreign networks such as 271 a hotel, hot spot etc where the client may gain access to the 272 network but does not know the credentials to authenticate with the 273 PCP server. 275 a. An SA MUST be made available to the client and server, which 276 will be used for integrity protection of PCP messages. The 277 negotiation of SA should be secure such that the SA is only 278 known to the anonymous client and PCP server. 280 b. A PCP client MUST be able to validate that it is communicating 281 with the designated PCP server and not an attacker posing as a 282 PCP server. 284 6. IANA Considerations 286 This document does not require any action from IANA. 288 7. Security Considerations 290 This entire document is about security considerations for PCP. 292 8. References 294 8.1. Normative References 296 [I-D.ietf-pcp-base] 297 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 298 Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp- 299 base-29 (work in progress), November 2012. 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, March 1997. 304 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 305 4949, August 2007. 307 8.2. Informative References 309 [BitTorrent] 310 , "Cohen, B., "The BitTorrent Protocol Specification 311 Version 11031", February 2008.", September 2012. 313 [I-D.ietf-pcp-proxy] 314 Boucadair, M., Penno, R., and D. Wing, "Port Control 315 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-02 316 (work in progress), February 2013. 318 [I-D.ietf-rtcweb-overview] 319 Alvestrand, H., "Overview: Real Time Protocols for Brower- 320 based Applications", draft-ietf-rtcweb-overview-06 (work 321 in progress), February 2013. 323 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 324 A., Peterson, J., Sparks, R., Handley, M., and E. 325 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 326 June 2002. 328 Appendix A. Change History 330 A.1. Change from -01 to -02 332 o Requirements reorganized based on commonality 334 o New requirement 3(c(2)) added. 336 A.2. Change from -02 to -03 338 o Merged REQ-1 and REQ-7 340 o Updated Section 5 "Other recommendations" 342 Authors' Addresses 344 Tirumaleswar Reddy 345 Cisco Systems, Inc. 346 Cessna Business Park, Varthur Hobli 347 Sarjapur Marathalli Outer Ring Road 348 Bangalore, Karnataka 560103 349 India 351 Email: tireddy@cisco.com 353 Prashanth Patil 354 Cisco Systems, Inc. 355 Bangalore 356 India 358 Email: praspati@cisco.com 360 Dan Wing 361 Cisco Systems, Inc. 362 170 West Tasman Drive 363 San Jose, California 95134 364 USA 366 Email: dwing@cisco.com 367 Reinaldo Penno 368 Cisco Systems, Inc. 369 170 West Tasman Drive 370 San Jose, California 95134 371 USA 373 Email: repenno@cisco.com