Re: [abfab] Fwd: New Version Notification for draft-perez-abfab-wg-arch-erp-00.txt

[Alejandro Perez Mendez <[e-mail]>]

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