From nobody Mon Oct 27 10:48:59 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DFF1A878E for ; Mon, 27 Oct 2014 10:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSJjPM9jn0DW for ; Mon, 27 Oct 2014 10:48:36 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 7494A1A883D for ; Mon, 27 Oct 2014 10:46:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 49429F4A for ; Mon, 27 Oct 2014 18:46:52 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BhQ5Sb6MXt2j for ; Mon, 27 Oct 2014 18:46:52 +0100 (CET) Received: from [10.42.0.18] (84.124.144.62.dyn.user.ono.com [84.124.144.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon23.um.es (Postfix) with ESMTPSA id 75D3BB312 for ; Mon, 27 Oct 2014 18:46:41 +0100 (CET) Message-ID: <544E8501.4060806@um.es> Date: Mon, 27 Oct 2014 18:46:41 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "abfab@ietf.org" References: <20141027173338.20163.8329.idtracker@ietfa.amsl.com> In-Reply-To: <20141027173338.20163.8329.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141027173338.20163.8329.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------030202040707060300020200" Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/XE-Rkpvd_qKV-ppesx8xY_46kuQ Subject: [abfab] Fwd: New Version Notification for draft-perez-abfab-wg-arch-erp-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:48:40 -0000 This is a multi-part message in MIME format. --------------030202040707060300020200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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.tx= t Fecha: Mon, 27 Oct 2014 10:33:38 -0700 De: internet-drafts@ietf.org Para: Alejandro Perez-Mendez , Alejandro Perez-Mendez , Rafa Marin-Lopez , Rafael Lopez , Gabriel Lopez-Millan , Gabriel Lopez-Millan , Fernando Pereniguez-Garcia , Fernando Pereniguez-Garcia 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 t= he 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-arc= h-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. = =20 Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------030202040707060300020200 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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: internet-drafts@ietf.org
Para: Alejandro Perez-Mendez <alex@um.es>, Alejandro Perez-Mendez <alex@um.es>, Rafa Marin-Lopez <rafa@um.es>, Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>, Gabriel Lopez-Millan <gabilm@um.es>, Fernando Pereniguez-Garcia <pereniguez@um.es>, Fernando Pereniguez-Garcia <pereniguez@um.es> 


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


--------------030202040707060300020200-- From nobody Mon Oct 27 11:46:13 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6A91A1B55 for ; Mon, 27 Oct 2014 11:45:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM5HGOCfP59O for ; Mon, 27 Oct 2014 11:45:47 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6351A889C for ; Mon, 27 Oct 2014 11:43:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B6258202C1; Mon, 27 Oct 2014 14:42:03 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQD-RbRT9gui; Mon, 27 Oct 2014 14:42:03 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 27 Oct 2014 14:42:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 218ED80513; Mon, 27 Oct 2014 14:43:40 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <20141027173338.20163.8329.idtracker@ietfa.amsl.com> <544E8501.4060806@um.es> Date: Mon, 27 Oct 2014 14:43:40 -0400 In-Reply-To: <544E8501.4060806@um.es> (Alejandro Perez Mendez's message of "Mon, 27 Oct 2014 18:46:41 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/a5ZprmfoHjm0q5iZ9RzH4dCJ6H4 Cc: "abfab@ietf.org" Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-abfab-wg-arch-erp-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 18:45:49 -0000 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 nobody Mon Oct 27 16:38:08 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E751A875E for ; Mon, 27 Oct 2014 16:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cWwWdcci2R8 for ; Mon, 27 Oct 2014 16:37:53 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF561A86E7 for ; Mon, 27 Oct 2014 16:37:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 5328AD832; Tue, 28 Oct 2014 00:36:59 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id vxpp1YKyphSI; Tue, 28 Oct 2014 00:36:59 +0100 (CET) Received: from [10.42.0.18] (84.124.144.62.dyn.user.ono.com [84.124.144.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon23.um.es (Postfix) with ESMTPSA id 32EEDCAA1; Tue, 28 Oct 2014 00:36:57 +0100 (CET) Message-ID: <544ED717.5010908@um.es> Date: Tue, 28 Oct 2014 00:36:55 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Sam Hartman References: <20141027173338.20163.8329.idtracker@ietfa.amsl.com> <544E8501.4060806@um.es> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/FNpW0CtfwaKD4dUSDvzdxpNDXCA Cc: "abfab@ietf.org" Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-abfab-wg-arch-erp-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 23:38:02 -0000 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. =20 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