Hi Sam, > Hi. > > When I first heard about this idea I mentioned that we had been working > with the idea of using Kerberos to handle rapid re-authentication. The > idea is that an acceptor can provide a Kerberos ticket to a RFC 7055 > implementation that can be returned for fast re-authentication. > > My feeling at the time is that is a better approach than ERP for ABFAB.
as you know, we do like Kerberos-based proposals. Indeed, my own PhD thesis is focused on the use of Kerberos for providing generic application federation support, and we have made some submissions to the ABFAB and Kerberos WG around this topic in the past. Hence, we have nothing against the use of Kerberos. In my opinion, the idea of making the acceptor generate a Kerberos ticket is ok if what you want is to provide fast re-authentication for future accesses to that particular acceptor. However, if you want to access to another acceptor within the federation, fast re-authentication will not work, as all of the acceptors would need to share the same Kerberos key. Having this sort of RP-to-RP fast re-authentication support is one of the major goals we have in the CLASSe project. In particular, we pursue providing SSO and fast re-authentication in RP-to-RP and network-to-RP scenarios. In addition to ERP, we have explored some Kerberos-based strategies, but we concluded that the most natural and standard way to provide this kind of fast re-authentication in ABFAB was using ERP. > > I never really saw a response to that comment. I recall having a discussion about this topic some time ago, but we didn't went into the details of the ERP-based solution until now, when we've been involved in the CLASSe project. As you've said, we knew about the Kerberos based approach you've mentioned. Moreover, I think you also mentioned it was at some extent implemented in Moonshot. However, as it does not cover the RP-to-RP scenario, it did not satisfy our requirements for the CLASSe project. Of course, it does not mean we are against the Kerberos-based proposal for the scenarios where that kind of fast re-authentication is enough. Indeed, that would be the most reasonable way to proceed in those scenarios, in order to avoid modifying the AAA infrastructure in order to support ERP. However, in our opinion, ERP is the way to proceed if you need RP-to-RP fast re-authentication. > As an experiment, it's > fine to go off and explore whatever approach you like. > However, at the point when you start proposing this work in the IETF, I > think we should explore other plausible alternatives. As such I think > we should have a discussion of ERP vs RFC 4121. Indeed, that's the main purpose of submitting this draft: propose a plausible alternative for this "problem" we had in CLASSe. We do not want to impose our view, just let the WG know about this proposal we designed. It is easier to discuss when you have a somehow detailed description written in a document. Others can have a better understanding of what you want to achieve, and how. I'll be in Honolulu, so if you are planning to attend, I'm looking forward to discuss this and any other topics of interest with you there. Regards, Alejandro > > --Sam _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
