idnits 2.17.1 draft-reddy-pcp-auth-req-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2013) is 3942 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-03 == 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: January 11, 2014 R. Penno 6 Cisco 7 July 10, 2013 9 PCP Authentication Requirements 10 draft-reddy-pcp-auth-req-04 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 January 11, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Third Party Authorization . . . . . . . . . . . . . . . . . . . 5 57 5. Other recommendations . . . . . . . . . . . . . . . . . . . . . 7 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 A.3. Change from -03 to -04 . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1. Introduction 71 This document derives requirements for PCP Authentication from PCP 72 deployment scenarios and scope described in [RFC6887] and other PCP 73 drafts. The document focuses on requirements and does not make a 74 suggestion on the authentication mechanism to be used to satisfy 75 requirements. 77 2. Terminology 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 This note uses terminologies defined in [RFC4949] such as realm, 84 security association, identity, credential etc. 86 3. Requirements 88 REQ-1: PCP MUST provide client authentication. PCP client and 89 server MUST also be able to mutually authenticate. Mutual 90 authentication is especially necessary when the PCP server is 91 located in a different administrative domain from the PCP client. 92 Credentials to gain access to the network could be different from 93 the credentials used to authenticate with the PCP server. 95 * The identity details of the client could be used by the PCP 96 server to grant access to certain PCP opcodes or PCP options. 97 For example GUESTS might not be permitted to use the MAP opcode 98 and only ADMINISTRATOR might be permitted to use the 99 THIRD_PARTY option. 101 * The identity details of the client could be used for auditing. 103 REQ-2: PCP Authentication MUST generate security association for 104 integrity protection of PCP request and response. This and all 105 subsequent requirements are not applicable to multicast PCP 106 responses like ANNOUNCE. 108 REQ-3: A PCP server MUST be able to indicate that a request will not 109 be processed without authentication. 111 REQ-4: If a PCP client authenticates with a PCP server, 113 A. The client MUST be able to verify the integrity and origin of 114 responses from the server. 116 B. The server MUST be able to send authenticated unsolicited 117 responses. 119 C. If a PCP response does not include integrity related to a 120 current security association, then those messages MUST NOT be 121 trusted without soliciting an integrity protected version. 123 D. The server MUST be able to trigger reauthentication with the 124 client. The unsolicited message for authentication trigger 125 MUST be integrity protected if there is a valid unexpired SA. 127 REQ-5: It is important that PCP not leak privacy information between 128 the PCP client and PCP server, 130 A. The authentication mechanism MUST be able to keep credentials 131 hidden from eavesdroppers on path between the client and 132 server. 134 B. Confidentiality of the PCP messages is OPTIONAL for PCP 135 request and response of opcodes MAP, PEER, ANNOUNCE and 136 options THIRD_PARTY, PREFER_FAILURE and FILTER as explained in 137 [RFC6887]. Other PCP drafts MUST evaluate if confidentiality 138 is OPTIONAL for new PCP opcodes and options introduced. 140 C. PCP authentication SHOULD be immune to passive dictionary 141 attacks. 143 D. PCP Authentication MUST ensure that an attacker snooping PCP 144 messages cannot guess the SA. 146 REQ-6: To ease troubleshooting and ensure fate sharing, PCP 147 authentication and PCP messages MUST be multiplexed over the same 148 port. 150 REQ-7: PCP authentication MUST accommodate authentication between 151 administrative domains. For example, a PCP client may wish to 152 communicate directly to an ISP's PCP server, even though the in- 153 home CPE router does not support PCP. In this scenario the PCP 154 client needs to directly authenticate with the ISP's PCP server. 156 REQ-8: For the scenarios described in REQ-7, the PCP authentication 157 mechanism MUST be functional across address and port translation, 158 including NAPT64 and NAPT44. 160 REQ-9: A PCP proxy that modifies PCP messages SHOULD have the 161 ability to independently authenticate with the PCP client and PCP 162 server. The presence of a PCP proxy hence requires two separately 163 authenticates SAs. As a consequence, the PCP proxy: 165 +------------+ | 166 | PCP Client |-----+ | 167 +--(Host 1)--+ | +-----------+ | +----------+ 168 +---| | | | | 169 | PCP Proxy |-------|PCP Server| 170 +---| | | | | 171 +------------+ | +-----------+ | +----------+ 172 | PCP Client |-----+ | 173 +--(Host 2)--+ possible boundary 174 <- Home side | ISP side -> 176 A. MUST be able to validate message integrity of PCP messages 177 from the PCP server and client respectively. 179 B. MUST be able to ensure message integrity after updating the 180 PCP message for cases described in sections 6 and 7 of 181 [I-D.ietf-pcp-proxy]. 183 The PCP proxy MUST also permit authentication on only one side of 184 the proxy. For example, a customer premises host may not 185 authenticate with the PCP proxy but the PCP proxy may authenticate 186 with the PCP server. 188 REQ-10: It is RECOMMENDED that PCP authentication support a 189 mechanism where authentication on one port MUST be usable on other 190 ports without requiring another authentication exchange for other 191 ports. For example, there could multiple applications on the host 192 like BitTorrent [BitTorrent], WebRTC[I-D.ietf-rtcweb-overview]/SIP 193 [RFC3261] using PCP. Multiple authentication exchanges increase 194 load on the PCP server and chatter on the network. For example, 195 if 'N' messages are to be exchanged for PCP authentication and 'M' 196 independent applications implement their own PCP client, a total 197 of N*M messages have to be exchanged and 'M' number of SAs 198 maintained for each host. 200 REQ-11: It is RECOMMENDED to choose a widely deployed authentication 201 technique with known security properties rather than inventing a 202 new authentication mechanism. 204 REQ-12: Changes in PCP to accommodate authentication SHOULD be 205 minimal so that updates and additions to the authentication 206 mechanism have minimal bearing on modifying PCP. 208 4. Third Party Authorization 210 REQ-13: In addition to a two party authentication that has been 211 discussed in this draft, a mechanism for third party authorization 212 MUST also be supported. This is applicable in cases where a third 213 party authorizes the use of a resource on a PCP server for a desired 214 PCP client. For example, as depicted in Figure 1 , a PCP request to 215 a PCP capable firewall authorized by a SIP proxy rather than by 216 virtue of the end user making the PCP request. The PCP server is to 217 permit a PCP MAP request from the PCP client if the user is making a 218 SIP call with the Enterprise or a trusted SIP server in 3rd party 219 network, otherwise do not allow MAP request from that particular 220 user. In this scenario the first party is the user, second party is 221 the PCP server (which is also the firewall) and the third party is 222 the SIP server, where the user is authorized to use MAP request only 223 when making a call using the trusted SIP Server. 225 ========================= 226 | SIP Server | 227 ========================= 228 | 3rd Party Network 229 | 230 | 231 ================== 232 | WAN |-----+-+----+---+----+-+--- 233 ================== | 234 | | 235 | | 236 | | 237 +-------+-------+ | 238 | Firewall - | | 239 | PCP Server | | 240 +-------+-------+ | 241 | | 242 | | 243 Network A | | Network B 244 -+-+-----+-----------+-+-----+-------- -----+-+-------+------ 245 | | 246 +-+------+ +--------+ 247 | Alice | | Bob | 248 +--------+ +--------+ 250 Users : Alice, Bob 252 Figure 1: WebRTC server in a different administrative domain 254 5. Other recommendations 256 REQ-14: There SHOULD be support for a means to provide integrity 257 protection without user authentication, i.e., an anonymous client 258 should be able to verify a PCP server using server-side-only auth 259 and as a consequence obtain an SA which will be used for PCP 260 message integrity. For example, a client visiting foreign 261 networks such as a hotel, hot spot etc where the client may gain 262 access to the network but does not know the credentials to 263 authenticate with the PCP server. The negotiation of SA should be 264 secure such that the SA is only known to the anonymous client and 265 PCP server. 267 6. IANA Considerations 269 This document does not require any action from IANA. 271 7. Security Considerations 273 This entire document is about security considerations for PCP. 275 8. References 277 8.1. Normative References 279 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 280 Requirement Levels", BCP 14, RFC 2119, March 1997. 282 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 283 RFC 4949, August 2007. 285 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 286 Selkirk, "Port Control Protocol (PCP)", RFC 6887, 287 April 2013. 289 8.2. Informative References 291 [BitTorrent] 292 "Cohen, B., "The BitTorrent Protocol Specification Version 293 11031", February 2008.", September 2012. 295 [I-D.ietf-pcp-proxy] 296 Boucadair, M., Penno, R., and D. Wing, "Port Control 297 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-03 298 (work in progress), June 2013. 300 [I-D.ietf-rtcweb-overview] 301 Alvestrand, H., "Overview: Real Time Protocols for Brower- 302 based Applications", draft-ietf-rtcweb-overview-06 (work 303 in progress), February 2013. 305 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 306 A., Peterson, J., Sparks, R., Handley, M., and E. 307 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 308 June 2002. 310 Appendix A. Change History 312 A.1. Change from -01 to -02 314 o Requirements reorganized based on commonality 316 o New requirement 3(c(2)) added. 318 A.2. Change from -02 to -03 320 o Merged REQ-1 and REQ-7 322 o Updated Section 5 "Other recommendations" 324 A.3. Change from -03 to -04 326 o Updated REQ-4, REQ-9 and REQ-14. 328 Authors' Addresses 330 Tirumaleswar Reddy 331 Cisco Systems, Inc. 332 Cessna Business Park, Varthur Hobli 333 Sarjapur Marathalli Outer Ring Road 334 Bangalore, Karnataka 560103 335 India 337 Email: tireddy@cisco.com 338 Prashanth Patil 339 Cisco Systems, Inc. 340 Bangalore 341 India 343 Email: praspati@cisco.com 345 Dan Wing 346 Cisco Systems, Inc. 347 170 West Tasman Drive 348 San Jose, California 95134 349 USA 351 Email: dwing@cisco.com 353 Reinaldo Penno 354 Cisco Systems, Inc. 355 170 West Tasman Drive 356 San Jose, California 95134 357 USA 359 Email: repenno@cisco.com