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

[Sam Hartman <[e-mail]>]

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



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

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.

--Sam