On Oct 19, 2012, at 3:59 PM, Sam Hartman <[email protected]> wrote:
Sam, The way I look at it is that you talk about two different types of authorisations, one where the AAA-server says "for the following x seconds my vouch for the fact that Sam has successfully authenticated and is associated with the following attributes" and the other where the resource owner decides what should happen once that assertion is not valid anymore. I don't believe it is the business of the AAA-server to say what the resource owner must do. If someone has configured my firewalls perfectly and now leaves for another company, I do want to make sure he can not mess with my configs anymore, but I definitely don;t want to have to redo all my configuration. At the same time, I can also imagine cases where you do want to roll back actions someone undertook. So all in all, this is application logic that I don't think we should try to specify. And indeed, for one particular application, like network access, it may make perfect sense to specify the behaviour explicitly. Klaas > > > 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 _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
