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

[<[e-mail]>]

Hi Prashanth,

From: Prashanth Patil (praspati) [mailto:[e-mail]]
Sent: Friday, July 19, 2013 9:57 PM
To: ohba yoshihiro; [e-mail]
Cc: [e-mail]; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Distribution is not a good approach, brings in too many additional problems. How does the PCP Server trust the proxy, how is the key distributed, should it all be facilitated over PCP etc ?
[YO] Key distribution is common in EAP/AAA (e.g., MSK distribution from AAA server to APs). Proxy itself needs to be authenticated by PCP server.  The resulting SA created between the proxy and server can be used as the secure channel for the key distribution. Details will need to be worked out, but I think we need to agree on the use case and requirement before entering into solution space.

Having said that I think the current PCP authentication requirements are still unclear  in terms of proxy support.

The above problems aside, as being discussed in other threads, the role of the PCP proxy is not just that of forwarding but also acting on the request, installing state etc and does all of this based on its own policy. Also, an ISP's PCP server does not need to know of the different users within the home and has no incentive to individually authenticate each of those different users - it's only interesting to the proxy (the PCP server as far as the individual home users are concerned).
For all these reasons, the two legs are independent and need to have independent authentication.
[YO] I agree that your model is definitely *a* valid use case, but my whole point is that there are other proxy use cases that would require end-to-end authentication between clients and server (e.g., public wifi hotspot).

Yoshihiro Ohba


-Prashanth

On 19/07/13 1:49 AM, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:

Well, that is easy: Once the PCP server successfully authenticate a PCP client, it distributes a key used for protecting PCP message between the PCP client and the PCP proxy to the PCP proxy in a secure way.

Regards,
Yoshihiro Ohba


From: Prashanth Patil (praspati) [mailto:[e-mail]]
Sent: Friday, July 19, 2013 1:23 AM
To: ohba yoshihiro; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Hi Yoshihiro,

On 18/07/13 8:59 PM, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Prashanth,


From: Prashanth Patil (praspati) [mailto:[e-mail]]
Sent: Friday, July 19, 2013 12:11 AM
To: ohba yoshihiro(大場義洋○ＲＤＣ□ＮＳＬ); [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Hi Yoshihiro,
Although the abstract says that, I don’t think the intent is for the PCP Proxy to just be a relay agent. It is clear from other sections of the draft that the proxy is indeed a server and needs to modify fields (albeit minimal) before forwarding them to the actual server. This implies two independent authentications need to happen.
[YO] I don’t understand your logic here. Even an http proxy can modify http requests (e.g., X-Forwarded-For header), and an http server can still authenticate http clients behind the proxy.

How does the proxy maintain message integrity if it modifies requests/responses? The case is different with HTTP.

-Prashanth

Yoshihiro Ohba

-Prashanth

On 18/07/13 7:09 PM, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> wrote:

Hi Tiru,

Abstract of pcp-proxy draft says:

“
   This document specifies a new PCP functional element denoted as PCP
   Proxy.  The PCP Proxy relays PCP requests received from PCP Clients
   to upstream PCP Server(s).  This function is mandatory when PCP
   Clients can not be configured with the address of the PCP Server
   located more than one hop.
“

If this abstract is correct, I interpret that PCP clients only know the PCP proxy’s address, but the PCP server *can* be the authentication end-point for the PCP clients.  This is similar to the http proxy case where http servers are the authentication end-points for http clients.  Having said that, I think it is a bad idea to mandate PCP proxy to be *the* end-point that authenticates the PCP clients in the proxy case.

Yoshihiro Ohba



From:[e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Prashanth Patil (praspati)
Sent: Wednesday, July 17, 2013 4:46 PM
To: Alper Yegin
Cc: [e-mail]<mailto:[e-mail]>; Tirumaleswar Reddy (tireddy)
Subject: Re: [pcp] Proxy security (was Re: CONSENSUS CALL on PCP security)

Hi Alper,

On 17/07/13 12:23 PM, "Alper Yegin" <[e-mail]<mailto:[e-mail]>> 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.

PRA: Yes, none of them are mandatory, it's currently the prerogative of the server to mandate authentication. The proxy MUST be able authenticate with either client or server or both.

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?

PRA: Right. As far as the client is concerned, the proxy is the PCP server. The proxy is in turn a client to the upstream PCP server. The two parts should be independent of each other.

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.

PRA: May be, but don’t know why the server would want to know the auth-id of a client.

-Prashanth

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:[e-mail]]
Sent: Monday, July 15, 2013 10:51 PM
To: Dave Thaler; [e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pcp

_______________________________________________
pcp mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/pcp