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

Dan Wing <dwing@cisco.com> Wed, 17 July 2013 18:11 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 95AB621E8091 for <pcp@ietfa.amsl.com>; Wed, 17 Jul 2013 11:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.508
X-Spam-Level:
X-Spam-Status: No, score=-110.508 tagged_above=-999 required=5 tests=[AWL=0.090, 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 KETy8z9s28-L for <pcp@ietfa.amsl.com>; Wed, 17 Jul 2013 11:11:23 -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 3F21721E8086 for <pcp@ietf.org>; Wed, 17 Jul 2013 11:11:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14963; q=dns/txt; s=iport; t=1374084680; x=1375294280; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=oUpVxk+C7FY+kYZ4vUbUbE/fHC0TLdZ+Gja0CZf3DHU=; b=T1os/YnxNziUu0wg6z9mEp1JbvR2iRsp3M0eL8l+alwxCq60UL8r1qh9 kTA6IiXmTjFuZQGhVpBfQCSLMJ6nTBNu4kvZ2s+2mLC7GtZI35X4ZTEM8 3rJLq9Xy197ehGs4ZbdWTkfVZ9uU+sxaMwveDxv70X+AEDLcGsJyzJLU4 o=;
X-IronPort-AV: E=Sophos; i="4.89,686,1367971200"; d="scan'208,217"; a="83268039"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 17 Jul 2013 18:11:19 +0000
Received: from sjc-vpn6-1086.cisco.com (sjc-vpn6-1086.cisco.com [10.21.124.62]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6HIBIOB022522; Wed, 17 Jul 2013 18:11:18 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_15780669-051C-4E3B-8BDA-B45D14130FDF"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <758747A2-EB6E-4581-BDE3-DD7798A77EDF@yegin.org>
Date: Wed, 17 Jul 2013 11:11:18 -0700
Message-Id: <3E000B89-C81D-4E0E-B810-92901F6A2E8E@cisco.com>
References: <B235506D63D65E43B2E40FD27715372E1CE320B6@xmb-rcd-x07.cisco.com> <758747A2-EB6E-4581-BDE3-DD7798A77EDF@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: Wed, 17 Jul 2013 18:11:27 -0000

On Jul 16, 2013, at 11:53 PM, Alper Yegin <alper.yegin@yegin.org> wrote:

> 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?

That is how I have modeled it in my head, yes.  Imagining a home network, there are "N" people and "MM" devices in the home.  Each person and each device might have its own credentials and its own permissions to do various things (e.g., I don't want to allow my Sony television to run a server).  My ISP does not care about my NNN people and MMMM devices; it only knows of one user, and only wants to know of one user (anything else is too hard for the ISP).  So, the PCP proxy enforces policies for the NNN people and MMMM devices, and the PCP proxy uses different credentials (and thus a different security association) to talk with the ISP's PCP server.  The per-user and per-device policy is "aggregated" by the PCP proxy.  The same would occur within an enterprise network, where there are NNN people and MMMM devices.

> 
> 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.

That's a different model, where the per-user / per-device policy is not aggregated by the PCP proxy; instead, the client's identity is propagated through the network.  I don't know if we need that model yet.

-d


> 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