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

"Prashanth Patil (praspati)" <praspati@cisco.com> Wed, 17 July 2013 13:05 UTC

Return-Path: <praspati@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 49E4021F9F6E for <pcp@ietfa.amsl.com>; Wed, 17 Jul 2013 06:05:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 Qc8p7KzMNTrO for <pcp@ietfa.amsl.com>; Wed, 17 Jul 2013 06:05:00 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8577821F9EEB for <pcp@ietf.org>; Wed, 17 Jul 2013 06:04:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41719; q=dns/txt; s=iport; t=1374066299; x=1375275899; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=pn8GrNIW/kBPlaMVEIrhAqGl6lc3nANmScosobqqTbU=; b=OT/tdrblTx9zwma8+Bug0ywLQvt3KAJ+NLZrsVMV+450s1HaW0YxEgVQ 6HFlhUrHuMO2Vbk09rMlSwksSmAksTk5eJjExWZSSgNUM2RACWj0u8Un5 mBW/jdL6azNNwTpW3l2501d1q6Hq9ZpOC9gpQqtHLwpXJhuNUVqlqvvpy c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqoFAIqV5lGtJXG+/2dsb2JhbABagkJENE+6FYg9gREWdIIjAQEBBAEBASRHCwwGAQgRBAEBCxYBBi4LFAkIAgQBDQUIE4d1DLVtjz0tBAYBBoMGbgOBTZc4kCSDEoFqJBo
X-IronPort-AV: E=Sophos; i="4.89,684,1367971200"; d="scan'208,217"; a="235720129"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 17 Jul 2013 13:04:45 +0000
Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6HD4iWR031642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 13:04:44 GMT
Received: from xmb-rcd-x07.cisco.com ([169.254.7.39]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 08:04:44 -0500
From: "Prashanth Patil (praspati)" <praspati@cisco.com>
To: Alper Yegin <alper.yegin@yegin.org>, "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Thread-Topic: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)
Thread-Index: AQHOgryWZGzXOvs7fU2hvWRltojzFZlpENsAgAB2EoA=
Date: Wed, 17 Jul 2013 13:04:44 +0000
Message-ID: <B235506D63D65E43B2E40FD27715372E1CE32669@xmb-rcd-x07.cisco.com>
In-Reply-To: <CC5BD63E-AD30-4D3E-A6CC-8932B9B3AF6C@yegin.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [173.39.67.75]
Content-Type: multipart/alternative; boundary="_000_B235506D63D65E43B2E40FD27715372E1CE32669xmbrcdx07ciscoc_"
MIME-Version: 1.0
Cc: "pcp@ietf.org" <pcp@ietf.org>
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: Wed, 17 Jul 2013 13:05:05 -0000

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<mailto: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<mailto: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<mailto: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<mailto:pcp@ietf.org>
https://www.ietf.org/mailman/listinfo/pcp

_______________________________________________
pcp mailing list
pcp@ietf.org<mailto:pcp@ietf.org>
https://www.ietf.org/mailman/listinfo/pcp