Re: [pcp] EAP-over-PCP

[Margaret Wasserman <[e-mail]>]

Hi Alper,

On Sep 20, 2012, at 5:01 AM, Alper Yegin wrote:
>> Why do you think that we need to support EAP re-authentication? 
>> 
> 
> EAP re-authentication is one of the EAP events, and any EAP lower-layer has to support that.
> Otherwise, what? Your sessions have infinite lifetime? Authorization never changes? Never need to re-key? Never need to challenge the end-point again?
> These are the things that call for "re-authenticaiton", and why EAP has that, and why EAP lower-layers need to support that.

Sorry, I didn't see this response before I asked the question again...

EAP re-authentication is an optional extension to EAP -- it isn't part of the base EAP spec.  I understand why it is useful, in general, but it is not inherently part of EAP.  It has always been possible to start EAP over again from the beginning to do a new round of authentication, and that can be done periodically, as desired.  In other words, support for EAP re-authentication is not required to support re-keying or non-infinite lifetimes.

_Because_ PCP is a request/response protocol, it would be possible for either end to periodically throw away the existing authentication information for a peer, and perform/request a new round of authentication for the next request.  EAP re-authentication is not necessary for that purpose and, in fact, wouldn't be all that useful for that purpose with PCP -- we wouldn't want "sessions" to attempt to re-key repeatedly if there were no requests being sent back and forth, would we?  Please remember that PCP is a UDP request/response protocol, and the server may keep mappings open long after the client computers have gone home...  So, there is no hard concept of a PCP "session" that has a specific session lifetime.  Authentication may be required (in secure deployments) to create a mapping, but there is no notion that an authenticated session has to remain active for the mapping to remain in place for it's indicated lifetime.  In fact, it would be undesirable to create such a dependency, especially in the THIRD_PARTY/proxy case, because we would not want to create a situation where communication between two other nodes depends on the reliability/reachability of the PCP proxy.

You have asserted several times that EAP lower layers need to support retransmission and reauthentication, and Sam has asserted several times that they do not.  How do we resolve this disagreement?

Sam has pointed to an example of a recently approved EAP lower layer (more recent than PANA), gss-eap, that is simpler than PANA, supports a request/response model similar to PCP, and does not include those things.  So, it does not seem that the IETF (either the security area, or the IESG) currently enforces the rules that you are asserting.  Can you point to an RFC or some other reference that indicates that support for these things is required?  Or is it just your opinion that it is desirable to support these things for PCP?  If so, could you explain what benefits PCP would get from supporting them?

Could you perhaps look at gss-eap and consider whether a similar model could apply to PCP?  Would it be possible to achieve a similar model using PANA?  If so, what updates would be need to the PANA specification in order to do that?

Margaret