Re: [pcp] Comparison of PCP authentication

[Margaret Wasserman <[e-mail]>]

Hi Alper,

I am not entirely clear on what parts of these messages came from you or what parts you are replying to...  If I miss something you would like me to answer,
please let me know.

On Aug 2, 2012, at 5:30 PM, Alper Yegin wrote:

> http://www.ietf.org/proceedings/84/slides/slides-84-pcp-10.pdf
> 
> Ah, isn't it odd that this beauty contest is run by one of the contestants? This material should have been prepared and presented by a neutral party. 

There was a meeting between the available authors of both drafts this morning, and we worked together to make the slides reflect a fair comparison of the two approaches.

> One important question: With this proposal, are the authors advocating each protocol should come with their own in-band key management, more specifically embedding an EAP transport?

With which proposal?

I do, personally, think it is valid that there would be several different protocols that use EAP directly for authentication.  I think there already are...

> > what's the big deal of using the same port vs different port? Is jamming all in the same port is a benefit?

Having a protocol that relies on two ports (like the PCP Port and a PANA port) is more complex, operationally, because it requires that any intermediate firewalls or middleboxes be configured to pass both protocols in order for authenticated PCP to function properly.  

No one has indicated that this is a big deal, as far as I know.  It is one specific difference between two proposals that are, in many ways, quite similar.  There are other differences, as well, such as the fact that PANA has running code and the non-EAP portions of the in-band approach do not.

Need to specify the portions of PANA that don’t need to be implemented
> 
> in a PCP PANA Client and Server (such as IP Address reconfiguration)
> 
> >> this is just a single bit flag. We don't use it, and that's all we need to do about it.
One of the questions I have is:

What happens if a PANA Client that is trying to get authentication for PCP talks to a PANA Server that does Network Access authentication but _not_ PCP authentication...  The newest proposal (draft-ohba) does not indicate that any flag or value will be included in the PANA authentication request that indicates that the request is for Network Access authentication or PCP Authentication, so how will the PANA server know which to authenticate, and how will the client know what it has been authenticated _for_?
> Need to specify/describe interface between PANA and PCP elements
> 
> >> this is an implementation issue, like how the other spec implementors would need to define the interface between the EAP and PCP for passing keys, etc.
> 
Even in the case (as described in draft-ohba) where these elements run on a single system, it is necessary to specify what information is passed between these elements and what portion of it is passed in the PCP authentication options.  This is necessary, in order to ensure that the PANA authentication is properly bound to a PCP request.  Without specifying that information, it isn't possible to know that a particular PCP request/response has been properly bound to a particular PANA authentication.
> Need to specify how the PANA client finds the correct PANA Server for PCP Authentication (may be passed from PCP client?)
> >> PCP server the the PAA are the same node.

You have suggested that a huge advantage of using PANA for this application is that there could be code reuse with existing PANA implementations.  Existing PANA implementations don't find their PAA by looking at their PCP Server address...  They also don't have any notion (as far as I can tell) of a "client" that is invoking them to initiate authentication, or of a client and server to whom they should communicate the security association information after they negotiate it.   If the PCP client does not _tell_ PANA the address of the PCP Server to which it intends to send a request, how will the PANA client know?

Margaret