Another issue that has come up in the PCP discussions is the question of authorization lifetimes. Various AAA documents including the EAP keying framework limit the session lifetime based on what you get back from AAA. In the case of network access, that's kind of obvious: your ability to send packets is limited by the lifetime. There's a lot of discussion of complexity surrounding pre-authentication, but the general concept is only mildly complex.
It's more complex with applications. If I go commit some source code, that change will persist well past my ssh session. PCP is a NAT/firewall management protocol. It creates NAT mappings among other things. There has been some heated debate about whether the lifetime of these mappings should be dependend on the authentication session. One argument is that during the authentication session, you are authorized to make mapping changes. The server gets to decide how long those mappings are using whatever policy it likes. The server can limit things to the authentication session lifetime if it likes. Another argument is that the PCP security protocol should place requirements on this like the AAA keying framework does for network sessions. the question of what PCP should do belongs in that WG; I don't want to discuss it here. However, I think we should clarify whether EAP or AAA has anything to say about this. I think the answer is that AAA has a session lifetime, but what that means for applications and what persists beyond that session needs to be decided by those apps. I'd like to have fairly clear text that this is an application decision and that EAP and AAA are not trying to define the extent of a session or lifetime for applications. Other people involved in the PCP discussion may disagree with me and prefer that EAP/AAA define this for apps. --Sam _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
