idnits 2.17.1 draft-reddy-pcp-auth-req-01.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 (February 25, 2013) is 4078 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) == 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: 0 errors (**), 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: August 29, 2013 R. Penno 6 Cisco 7 February 25, 2013 9 PCP Authentication Requirements 10 draft-reddy-pcp-auth-req-01 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 August 29, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. Third Party Authorization . . . . . . . . . . . . . . . . . . . 5 57 5. Other recommendations . . . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 This document derives requirements for PCP Authentication from PCP 68 deployment scenarios and scope described in PCP-base 69 [I-D.ietf-pcp-base] and other PCP drafts. The document focuses on 70 requirements and does not make a suggestion on the authentication 71 mechanism to be used to satisfy requirements. 73 2. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 3. Requirements 81 REQ-1: PCP client and server MUST provide client authentication. 82 The client could be a host running a PCP client or middle box 83 (e.g., NAT) running a PCP Proxy. 85 * The identity details of the client could be used by the PCP 86 server to grant access to certain PCP opcodes or PCP options. 87 For example GUESTS would not be permitted to use MAP opcode, 88 ADMINISTRATOR is only permitted to use THIRD_PARTY option. 90 * The identity details of the client could be used for auditing. 92 PCP Authentication MUST also generate message authentication key 93 for integrity protection of PCP request and response. 95 REQ-2: PCP Servers MUST be able to indicate that a request will not 96 be processed without authentication. 98 REQ-3: PCP allows a server to send multiple responses. To properly 99 support that model with authentication, a client that sends an 100 authenticated request MUST be able to verify the integrity and 101 origin of an subsequent unsolicited response should it choose to 102 do so. 104 REQ-4: PCP allows a server to send multiple responses. If the 105 original request/response exchange was authenticated, a server 106 MUST be able to send a subsequent authenticated unsolicited 107 Response. 109 REQ-5: PCP allows a server to send multiple responses. If the 110 server wants to send an unsolicited message, but the previous 111 security association has expired, the server MUST be able to 112 trigger re-authentication with the client. 114 REQ-6: Clients that have authenticated with the server MUST verify 115 the integrity of the contents of all unsolicited responses. 117 REQ-7: If there are circumstances where PCP responses do not include 118 integrity related to a current security association, then those 119 messages MUST NOT be trusted without soliciting an integrity 120 protected version. 122 REQ-8: It is important that PCP not leak privacy information between 123 the PCP client and the PCP server(s). Thus, the PCP 124 authentication MUST NOT exchange the PCP clients authentication 125 credentials in clear text. For example, exchanging the PCP 126 username in clear text would violate this requirement. 128 REQ-9: Confidentiality of the PCP messages is OPTIONAL for PCP 129 request and response of opcodes MAP, PEER, ANNOUNCE and options 130 THIRD_PARTY, PREFER_FAILURE and FILTER explained in PCP-base 131 [I-D.ietf-pcp-base]. Other PCP drafts MUST evaluate if 132 confidentiality is OPTIONAL or not for new PCP opcodes and options 133 introduced. 135 REQ-10: The authentication mechanism SHOULD be immune to passive 136 dictionary attacks. 138 REQ-11: PCP Authentication MUST ensure that an attacker snopping the 139 PCP messages cannot guess the SA. 141 REQ-12: To ease troubleshooting and ensure fate sharing, the PCP 142 authentication and PCP messages MUST be multiplexed over the same 143 port. 145 REQ-13: PCP authentication MUST accommodate authentication between 146 administrative domains. For example, a PCP client may wish to 147 communicate directly to an ISP's PCP server, even though the in- 148 home CPE router does not support PCP. In this scenario the PCP 149 client needs to directly authenticate with the ISP's PCP server. 151 REQ-14: PCP client MUST be able to ascertain that it is talking to 152 the right PCP server, especially when PCP server is located in a 153 different administrative domain. 155 REQ-15: For the scenarios described in REQ-13, PCP authentication 156 mechanism MUST be functional across address and port translation, 157 including NAPT64 and NAPT44. 159 REQ-16: If a PCP client and server desire authentication then a PCP 160 proxy, that modifies PCP request/response before forwarding 161 messages, MUST validate message integrity of PCP messages from the 162 PCP server and client respectively. 164 +------------+ | 165 | PCP Client |-----+ | 166 +--(Host 1)--+ | +-----------+ | +----------+ 167 +---| | | | | 168 | PCP Proxy |-------|PCP Server| 169 +---| | | | | 170 +------------+ | +-----------+ | +----------+ 171 | PCP Client |-----+ | 172 +--(Host 2)--+ possible boundary 173 <- Home side | ISP side -> 175 REQ-17: PCP Proxy must also ensure message integrity after updating 176 the PCP message for cases described in sections 6 and 7 of 177 [I-D.ietf-pcp-proxy]. 179 REQ-18: PCP authentication SHOULD support a mechanism where only one 180 PCP client on the host will authenticate with the PCP server and 181 any other PCP clients SHOULD be able to reuse the previously 182 negotiated key for integrity protection. For example, multiple 183 applications on the host like BitTorrent [BitTorrent], 184 WebRTC[I-D.ietf-rtcweb-overview]/SIP [RFC3261] using PCP. 186 REQ-19: All else equal, it is RECOMMENDED to choose a widely 187 deployed authentication technique with known security properties 188 rather than inventing a new authentication mechanism. 190 REQ-20: Changes in PCP to accommodate authentication SHOULD be 191 minimal so that updates and additions to the authentication 192 mechanism have no bearing on modifying PCP. 194 4. Third Party Authorization 196 In addition to two party authentication that has been discussed in 197 this draft, a mechanism for third party authorization must also be 198 supported. This is required in cases where a third party authorizes 199 the use of a resource on a PCP server for a desired PCP client. For 200 example, a PCP request to a PCP capable firewall authorized by a SIP 201 proxy rather than by virtue of the end user making the PCP request. 203 The PCP server is to permit a PCP MAP request if a user is making a 204 SIP call with the Enterprise SIP server, otherwise do not allow MAP 205 request from that particular user. In this scenario the first party 206 is the user, second party is the PCP server (which is also the 207 firewall) and the third party is the SIP Server, where the user is 208 authorized to use MAP request only when making a call using the 209 trusted SIP Server. 211 5. Other recommendations 213 o Upon receiving a challenge with a certain REALM, if the PCP client 214 does not have credentials for that REALM, it SHOULD attempt to use 215 the username GUEST and password GUEST. The GUEST credentials are 216 expected to be configured on infrastructure where PCP 217 authentication is not necessary, but such guest users are given 218 some (minimal) authorization to use PCP. This addresses the 219 problem when the client is visiting foreign networks like hotel, 220 hot spot etc where it may gain access to the network but does not 221 know the credentials to authenticate to the ISP's PCP server when 222 the in-home CPE router does not support PCP and the PCP client 223 needs to directly authenticate with the ISP's PCP server (REQ-14). 225 6. IANA Considerations 227 This document does not require any action from IANA. 229 7. Security Considerations 231 This document does not define an architecture nor a protocol; as such 232 it does not raise any security concerns. 234 8. References 236 8.1. Normative References 238 [I-D.ietf-pcp-base] 239 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 240 Selkirk, "Port Control Protocol (PCP)", 241 draft-ietf-pcp-base-29 (work in progress), November 2012. 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 8.2. Informative References 248 [BitTorrent] 249 "Cohen, B., "The BitTorrent Protocol Specification Version 250 11031", February 2008.", September 2012. 252 [I-D.ietf-pcp-proxy] 253 Boucadair, M., Penno, R., and D. Wing, "Port Control 254 Protocol (PCP) Proxy Function", draft-ietf-pcp-proxy-02 255 (work in progress), February 2013. 257 [I-D.ietf-rtcweb-overview] 258 Alvestrand, H., "Overview: Real Time Protocols for Brower- 259 based Applications", draft-ietf-rtcweb-overview-06 (work 260 in progress), February 2013. 262 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 263 A., Peterson, J., Sparks, R., Handley, M., and E. 264 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 265 June 2002. 267 Authors' Addresses 269 Tirumaleswar Reddy 270 Cisco Systems, Inc. 271 Cessna Business Park, Varthur Hobli 272 Sarjapur Marathalli Outer Ring Road 273 Bangalore, Karnataka 560103 274 India 276 Email: tireddy@cisco.com 278 Prashanth Patil 279 Cisco Systems, Inc. 280 Bangalore 281 India 283 Email: praspati@cisco.com 284 Dan Wing 285 Cisco Systems, Inc. 286 170 West Tasman Drive 287 San Jose, California 95134 288 USA 290 Email: dwing@cisco.com 292 Reinaldo Penno 293 Cisco Systems, Inc. 294 170 West Tasman Drive 295 San Jose, California 95134 296 USA 298 Email: repenno@cisco.com