Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Dan Wing <dwing@cisco.com> Fri, 19 July 2013 02:40 UTC

Return-Path: <dwing@cisco.com>
X-Original-To: pcp@ietfa.amsl.com
Delivered-To: pcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D62E21E819D for <pcp@ietfa.amsl.com>; Thu, 18 Jul 2013 19:40:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.47
X-Spam-Level:
X-Spam-Status: No, score=-110.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcpDhKbB9DR5 for <pcp@ietfa.amsl.com>; Thu, 18 Jul 2013 19:40:13 -0700 (PDT)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id EE10821E8138 for <pcp@ietf.org>; Thu, 18 Jul 2013 19:40:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=68810; q=dns/txt; s=iport; t=1374201612; x=1375411212; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=AncNdJPUvMJJjRvCwGu3hMPoVJ6Pn0lLvHjR2pm82x8=; b=CbCnnb5eEZK208TKY5XS8A4wmxi1ckdo5dk+lfyTqsnaKOEQZ4LWT9S9 igix9ucL+W3+9h6gNP4uKWXBdFxk+SBY/2eCpXeFnsJkqaomRYKLnfNdG /GAcuYvqvMaa+YvloffAHElIqMwb85y5ra5rMRyjhToXAdZKVTAwwPFCl 4=;
X-IronPort-AV: E=Sophos; i="4.89,698,1367971200"; d="scan'208,217"; a="83410787"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 19 Jul 2013 02:40:11 +0000
Received: from [10.156.16.29] ([10.156.16.29]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6J2eAWw015427; Fri, 19 Jul 2013 02:40:10 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_0664061B-E324-4932-965D-FC07F80D110A"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <DD78AF33-5B11-4DAF-8368-DA815AD9C120@yegin.org>
Date: Thu, 18 Jul 2013 19:40:10 -0700
Message-Id: <29FF27C0-5713-4DB1-8F4D-41F463BAE27E@cisco.com>
References: <B235506D63D65E43B2E40FD27715372E1CE32669@xmb-rcd-x07.cisco.com> <3F203C46-59BE-4F5B-A4D5-B6DDADB107E7@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C327@xmb-rcd-x10.cisco.com> <3F1B99E5-B6A0-4149-A58E-0A80838874C1@yegin.org> <913383AAA69FF945B8F946018B75898A14B9C776@xmb-rcd-x10.cisco.com> <DD78AF33-5B11-4DAF-8368-DA815AD9C120@yegin.org>
To: Alper Yegin <alper.yegin@yegin.org>
X-Mailer: Apple Mail (2.1508)
Cc: "pcp@ietf.org" <pcp@ietf.org>, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)
X-BeenThere: pcp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PCP wg discussion list <pcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pcp>, <mailto:pcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pcp>
List-Post: <mailto:pcp@ietf.org>
List-Help: <mailto:pcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcp>, <mailto:pcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2013 02:40:17 -0000

On Jul 18, 2013, at 6:43 AM, Alper Yegin <alper.yegin@yegin.org> wrote:

> Hi Tiru,
> 
> I'd expect the PCP proxy to be as transparent and as light-weight as possible. Therefore, I'd normally expect the policy-based decision be made and executed on the PCP server. 
> Besides, PCP server is the real end-point consuming requests of the PCP client.

The PCP proxy is acting on the PCP requests, too, because the PCP proxy in a home (or a coffee shop) is very likely doing IPv4 NAT for all the reasons people do IPv4 NAT in homes and coffee shops.  When it does that, it necessarily also needs to change the source port number inside the PCP request.  For a concrete example, consider two hosts in a home, both listening on TCP/80, and both asking for TCP/80 mappings; one of them will be first and get what it wants (port 80 on the 'external' side of the home NAT), the other will get assigned some other port on 'external' side of the in-home NAT.  This gets repeated again on the ISP's PCP server, if the ISP is also operating its own NAT.

> Therefore it is simpler to let the PCP server apply the policy on its own responses.
> 
> Btw, can the PCP proxy and the PCP server belong to two separate ISPs?
> If so, would the PCP server be satisfied if it receives the "user's authenticated ID", or would it require to authenticate the user itself? 

The ISP's PCP server does not need to know of the different users within the home --- exactly like PSTN telephone service where mom (or dad) gets the bill and anybody in the home can make a long distance phone call to Timbuktu. The ISP has little business incentive to have that awareness; the subscriber's CPE (running a PCP proxy) can solve that problem and know about the NNN users in the home, control things by time-of-day, and all the other things that are done on sophisticated residential CPE today.

-d


> 
> Alper
>  
> 
> 
> 
> On Jul 18, 2013, at 4:16 PM, Tirumaleswar Reddy (tireddy) wrote:
> 
>> Hi Alper,
>>  
>> Please see inline [TR]
>>  
>> From: Alper Yegin [mailto:alper.yegin@yegin.org] 
>> Sent: Thursday, July 18, 2013 1:37 PM
>> To: Tirumaleswar Reddy (tireddy)
>> Cc: pcp@ietf.org
>> Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)
>>  
>> Tiru,
>>  
>> I'm talking about "public WiFi hotspot". Like in coffee shops.
>> The PCP proxy and the PCP server are either owned by the same ISP, or two separate business entities.
>> The users who attach to the hotspot are all distinct subscribers with distinct service plans. This is different than how all members of my house appears to the ISP, or all employees appears to the enterprise network administration. 
>> So, the PCP service provided to each user may differ. Maybe not all users are allowed to control some certain ports.  For PCP server to be able to act based on the Id of the users, it needs to know who they are as the requests are proxies by the PCP proxy.
>>  
>> [TR]
>>  
>> If the PCP Proxy and PCP server belong to the same ISP, why can’t the PCP Proxy itself enforce the subscriber-based policy ?
>> I do not understand why PCP Proxy cannot enforce identity-based policies for PCP, if you could explain or point to more details how the topology looks like ?, How PCP Auth works in this use with PCP proxy works in this use case ? it will help.
>>  
>> Thanks and Regards,
>> --Tiru.
>>  
>> Alper
>>  
>>  
>>  
>>  
>>  
>>  
>> On Jul 18, 2013, at 9:37 AM, Tirumaleswar Reddy (tireddy) wrote:
>> 
>> 
>>  
>> From: Alper Yegin [mailto:alper.yegin@yegin.org] 
>> Sent: Wednesday, July 17, 2013 8:07 PM
>> To: Prashanth Patil (praspati)
>> Cc: Tirumaleswar Reddy (tireddy); pcp@ietf.org
>> Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)
>>  
>> For the home gateway case, yes I'd think so.
>> Could we not apply PCP proxy case to public WiFi hotspots? There in that case the terminals attaching to the AP are distinct subscribers.
>>  
>> I did not get the use case, though there are distinct subscribers attached to the WLC (MAG), wouldn’t WLC act as PCP Proxy and communicate with the PCP Server in ISP to which it’s a single subscriber.
>>  
>> This looks just like Enterprise deployment where there are multiple users (similar to distinct subscribers attached to AP) communicating with the PCP server in the Enterprise Network, the PCP server in the campus would act as PCP proxy communicating with the ISP (PCP Server) to which it’s a single subscriber.
>>  
>> --Tiru.
>>  
>> Alper
>>  
>>  
>>  
>> On Jul 17, 2013, at 4:04 PM, Prashanth Patil (praspati) wrote:
>> 
>> 
>> 
>> Hi Alper,
>> In the example below, wont the ISP consider all users behind the home router as a single subscriber and not differentiate among individual users? Essentially, the PCP Server would treat the proxy (i.e the home router) as a single subscriber.
>>  
>> -Prashanth
>>  
>> On 17/07/13 5:02 PM, "Alper Yegin" <alper.yegin@yegin.org> wrote:
>>  
>> If the PCP server wants to provide some sort of differentiated service to the subscribers (e.g., different mapping lifetime), then it needs to know the authenticated ID of the subscriber.
>>  
>> Alper
>>  
>>  
>> On Jul 17, 2013, at 10:09 AM, Tirumaleswar Reddy (tireddy) wrote:
>> 
>> 
>> 
>> Please see inline [TR]
>>  
>> From: Alper Yegin [mailto:alper.yegin@yegin.org] 
>> Sent: Wednesday, July 17, 2013 12:24 PM
>> To: Prashanth Patil (praspati)
>> Cc: pcp@ietf.org; Tirumaleswar Reddy (tireddy)
>> Subject: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)
>>  
>> Hi Prashanth,
>>  
>> 
>> 
>> 
>> 
>> I'm not sure if enough thought went into the PCP Proxy security. As much as I'd love to be DONE! with this discussion, I also want to make sure people feel comfortable having thought all aspects around the proxy use. For (very important) example, what kind of security associations are needed for securing the proxy use: An SA btw client and server, an SA btw client and proxy, an SA btw proxy and server -- which combinations of these are needed?
>>  
>> We've included this in the updated version of auth req:
>>  
>> REQ-9: A PCP proxy that modifies PCP messages SHOULD have the
>> ability to independently authenticate with the PCP client and PCP
>> server. The presence of a PCP proxy hence requires two separately
>> authenticates SAs. As a consequence, the PCP proxy:
>>  
>> A. MUST be able to validate message integrity of PCP messages
>> from the PCP server and client respectively.
>>  
>> B. MUST be able to ensure message integrity after updating the
>> PCP message for cases described in sections 6 of ietf-pcp-proxy.
>>  
>> The PCP proxy MUST also permit authentication on only one side of
>> the proxy. For example, a customer premises host may not
>> authenticate with the PCP proxy but the PCP proxy may authenticate
>> with the PCP server.
>>  
>>  
>>  
>> So:
>>  
>> - We have two types of SAs. One between the client and the proxy, another between the proxy and the server.
>> - None of them are mandatory to use.
>>  
>> For each one that needs to be used, we need to perform authentication between the end-points. 
>> (e.g., between client and proxy).
>>  
>> So, in a way, we are dealing with security in two independent parts; client to proxy, and proxy to server. 
>> They are totally segregated from security perspective. 
>>  
>>  
>> Right?
>>  
>> Hmm, one thing: The server may need to know the authenticated ID of the client. Since it's not part of the client authentication, it won't know that value readily. So, we may need to define an option to carry that piece of information from the proxy to the server.
>>  
>> [TR]
>>  
>> Why would the PCP server need to know the authentication ID of the client. For example Home network;   Alice (PCP client) -> Home Router (PCP Proxy) -> ISP (PCP Server)
>> Why would PCP Server in ISP care about the authentication ID of Alice ?
>>  
>> --Tiru.
>>  
>> Alper
>>  
>>  
>>  
>> 
>> 
>> 
>> 
>> -Prashanth
>>  
>> Then we need to talk about how we dynamically create those using any one of these solutions.
>>  
>> Alper
>>  
>>  
>>  
>>  
>>  
>> On Jul 16, 2013, at 7:50 PM, Dave Thaler wrote:
>>  
>> -----Original Message-----
>> From: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com]
>> Sent: Monday, July 15, 2013 10:51 PM
>> To: Dave Thaler; pcp@ietf.org
>> Subject: RE: [pcp] CONSENSUS CALL on PCP security
>> Hi Dave,
>> In the poll when you refer to PANA, please clarify the draft you are referring
>> to http://tools.ietf.org/html/draft-ohba-pcp-pana-04 or
>> http://tools.ietf.org/html/draft-ohba-pcp-pana-encap-01 ?
>> --Tiru.
>> The question is intentionally agnostic as this is about a general approach,
>> not which specific implementation.  If it helps, you can interpret the
>> answer as "which of the two you think is better".
>> If the consensus is PANA rather than direct EAP-in-PCP, then we could
>> ask as a follow-up question which of the two we should go with. If
>> you'd like to include your answer to that now though, feel free to
>> include that in your response to the call.
>> -Dave
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
>>  
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp
>>  
>>  
> 
> _______________________________________________
> pcp mailing list
> pcp@ietf.org
> https://www.ietf.org/mailman/listinfo/pcp