On Nov 14, 2012, at 5:44 PM, Sam Hartman wrote: >>>>>> "Alan" == Alan DeKok <[email protected]> writes: > > Alan> For PCP, it's reasonable that the application knows the EAP > Alan> session has timed out. It can re-establish it before sending > Alan> the next message. Or, if messages are rare, it can wait and > Alan> re-establish it later. > > Well, it's a bit tricky to re-establish the session if the next message > is coming from the server but only the client can start the > authentication. > I think you have two general options: > > 1) Decide it's OK not to re-establish the session until the client wants > to do so >
This does not make sense. If we are talking about securing a protocol, that better be a complete security, not a partial security that's uncontrollably on and off. In this case, when the server wants to send a message, if it's lucky it'll find a live security association and send the message securely. If it's unlucky (there is no live SA), then bad luck -- packet is dropped w/o transmission. Because sending an unsecure packet does not make sense, it's at best useless, at worst harmful if we expect the clients to act on them. > 2) Change things and let the server start an EAP session. > > 3) Require the client to start an EAP session whenever the old session > goes away. > 2&3 make sense. I'd say the protocol shall support the capabilities needed for both 2 and 3. And leave it to the deployment to decide when to use them. > The details as they apply to PCP are best discussed on that list. Alper _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
