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

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 27 Oct 2014 18:46:41 +0100

Dear all,

we have submitted a new draft called "ERP extensions for the ABFAB
architecture". The draft aims to define the required extensions to make
the ABFAB architecture to support the execution of ERP exchanges, in
order to provide an enhanced fast re-authentication and Single Sign-On
(SSO) support, and a better resource utilization. This I-D is a result
from our work in the GN3plus OpenCall CLASSe project (www.um.es/classe).

In addition to the usual mailing list discussion, and although there
will not be an ABFAB meeting in Honolulu, I will be pleased to meet with
those of you attending the meeting and want to discuss the proposal,
provide critics, comments and/or feedback.

Regards,
Alejandro

-------- Mensaje reenviado --------
Asunto: 	New Version Notification for draft-perez-abfab-wg-arch-erp-00.txt
Fecha: 	Mon, 27 Oct 2014 10:33:38 -0700
De: 	[email-masked]
Para: 	Alejandro Perez-Mendez <[email-masked]>, Alejandro Perez-Mendez
<[email-masked]>, Rafa Marin-Lopez <[email-masked]>, Rafael Lopez <[email-masked]>,
Gabriel Lopez-Millan <[email-masked]>, Gabriel Lopez-Millan
<[email-masked]>, Fernando Pereniguez-Garcia <[email-masked]>, Fernando
Pereniguez-Garcia <[email-masked]>

A new version of I-D, draft-perez-abfab-wg-arch-erp-00.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Name:		draft-perez-abfab-wg-arch-erp
Revision:	00
Title:		ERP extensions for the ABFAB architecture
Document date:	2014-10-27
Group:		Individual Submission
Pages:		16
URL:            http://www.ietf.org/internet-drafts/draft-perez-abfab-wg-arch-erp-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perez-abfab-wg-arch-erp/
Htmlized:       http://tools.ietf.org/html/draft-perez-abfab-wg-arch-erp-00

Abstract:
   The Application Bridging for Federated Access Beyond Web (ABFAB)
   architecture [I-D.ietf-abfab-arch] allows the use of EAP to perform
   access control to a wide range of applications.  This document
   describes the extensions required to incorporate support for the EAP
   Extensions for the EAP Re-authentication Protocol (ERP) to this
   architecture, in order to provide an enhanced fast re-authentication
   and Single Sign-On (SSO) support and a better resource utilization.
   Authorization aspects are also described.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2014 14:43:40 -0400

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.

I never really saw a response to that comment.  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.

--Sam

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 28 Oct 2014 00:36:55 +0100

Hi Sam,

> 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

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