Re: [pcp] EAP-over-PCP

[Alper Yegin <[e-mail]>]

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

It's not an extension, it's not an option.
It's merely executing EAP again, whether initiated by the EAP peer or the EAP authenticator -- for the reasons Sam and I listed before (rekeying, reautz, etc).

What it means for the EAP lower layer is that it shall be able to transport unsolicited payloads from each side, including the server-side. Which you are lacking right now. And I suspect you are resisting that addition because EAP-o-PCP would look even less like PCP once you add that.


> I understand why it is useful, in general, but it is not inherently part of EAP.

Running EAP again, or n-times, is naturally part of EAP. 
EAP initiation on the server side is the "EAP standard".


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

Yes, that's right. Also realize that this can be initiated by the client side or the network side. That's all I'm saying.

> In other words, support for EAP re-authentication is not required to support re-keying or non-infinite lifetimes.
> 


Confusing, what's that mean now? Once you perform re-auth, you get new keys and a new lifetime. Getting fresh keys and extending the lifetime are two of the reasons for performing re-auth.


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

How does the "server" side do that? That's the question. You need to define a message that can be transmitted from the server side to initiate re-auth.
It's not rocket science. It's doable. Just define it in EAP-o-PCP. I'm saying you are missing it. (but, I'm also saying your EAP-o-PCP is totally different than PCP).


> 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?  

EAP, and in fact any authenticated session, always comes with a finite lifetime. Even if you were sitting idle, you need to re-auth and extend the lifetime sometime before the current lifetime expires. Gotta do that.


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


Really??? I hope not. If a client disappears, is your NAT/firewall going to keep the state "forever"? 


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

That's right. But next time a PCP message needs to be sent/received related to a session, there better be a live SA. If there is no live SA, then one needs to "re-auth!" to get a live one.


> 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?
> 

Umm, he didn't explain why reauth/rexmit is not needed. Technical explanation is a good starting point, or a EAP-clueful person looks at this and makes a comment. 


> 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?
> 

We did explain that already, right? Even Sam made references to re-keying, lifetime, authorization change, etc.

I mean, this is one of the most basic things with security design. 
If we were in a security-specific group, you'd be the one explaining how you can get away w/o ever supporting re-auth.

If you guys think you have a magic to turn a server-driven protocol (EAP) into a client-drive protocol, and a magic to totally eliminate re-auth and yet still be have a secure solution with unconstrained applicability, please explain how you do that to us. 


> Could you perhaps look at gss-eap and consider whether a similar model could apply to PCP?  

I could look at it. And I guess now I have to. A simple technical explanation from Sam could be better than I having to read and digest that spec.

> 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?
> 

Confused. What updates to PANA for what purpose? PANA already supports re-auth. 


Alper