Re: [pcp] Implementation Analysis: strong preference for PCP-specific approach

[Alper Yegin <[e-mail]>]

On Sep 17, 2012, at 6:06 PM, Sam Hartman wrote:

>>>>>> "Alper" == Alper Yegin <[e-mail]> writes:
>>> Parts of the demultiplexing approach look simpler. You could run
>>> a PAA and PAC as separate processes. If the PCP server received
>>> an authentication request it could forward it to the PAA over a
>>> local socket. You'd need to make a slight change so that the
>>> return address could be preserved. In this mode, the PCP server
>>> would not need to change its state machine to wait for
>>> authentication.  Except then it gets complicated, because you
>>> need coordination between PCP and the PAC/PAA.  You need to
>>> design an implementation-specific protocol to:
>>> 
>>> * Trigger authentications on the PAC when PCP wants to talk to a
>>> server
>>> 
> 
>> Yes, we'd need to add a new trigger (PCP trigger).
> 
> 
>>> * update the PCP client on authentication state including session
>>> ID,key ID, and negotiated algorithms
>>> 
>>> * Provide error feedback from the PAC to PCP server so the user
>>> gets a consistent error reporting experience
>>> 
> 
>> We do not send error codes in PANA. Not sure which error reporting you are referring to.
> 
> Margaret has gone into this detail somewhat.
> The issue is that  you want a consistent experience  for the client.
> So, you need to do things like map PANA failures because the server
> doesn't support PANA into authentication not supported PCP errors.
> You need to log PANA and PCP errors in the same place.
> You need to provide consistent tools for looking at them.
> These are implementation not protocol issues.
> 

Right, these are implementation considerations.
Logging with the proper info, whether it's coming from PCP or PANA is what we need.
So that tools can parse them properly.


> 
> 
>>> * Update the PCP server on new authentication sessions at the PAA
>>> including IDs, keys and algorithm identifiers
>>> 
>>> If you do all that work you're going to end up with a fork of
>>> OpenPANA, not just get a library you can use and potentially
>>> refresh for new products/product releases.  Security analysis
>>> will be different especially for things like denial of service.
> 
>    Alper> Can you expand on this "DoS"?
> 
> 
> Sure.
> So, even in the demultiplexing case, we're coupling the state machines
> together.
> As an example we're creating a new PCP client state that is basically
> waiting for PANA.
> We need to do the security analysis for that.
> 

That state is "retrieve security parameters" for PCP.
Those parameters could be:
- retrieved from a configuration file (static)
- retrieved from dynamic store (from last unexpired authentication)
- if both are empty, then PANA is triggered to generate fresh parameters

Given that PANA is already analyzed, not sure what other threats might be in here.
(on the other hand, if you want to re-invent PANA within PCP from scratch, you've got lot of security analysis to make. That's a lot of work.)


> One of the simpler issues is a question like can an malicious server
> cause a PCP client to block indefinitely by swapping back and forth
> between PCP and PANA.
> 

Not sure if I understand the scenario… Can you elaborate?

Alper


> --Sam