[Secauth] My Summary of the December Conference Call
Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 08 January 2015 15:23 UTC
Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: secauth@ietfa.amsl.com
Delivered-To: secauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142E61A8A23 for <secauth@ietfa.amsl.com>; Thu, 8 Jan 2015 07:23:13 -0800 (PST)
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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 G7vSomCvwktI for <secauth@ietfa.amsl.com>; Thu, 8 Jan 2015 07:23:10 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78AAC1A8A93 for <secauth@ietf.org>; Thu, 8 Jan 2015 07:23:10 -0800 (PST)
Received: from [172.16.254.109] ([80.92.122.140]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LviG8-1Xjrqp3AWi-017RBV for <secauth@ietf.org>; Thu, 08 Jan 2015 16:23:07 +0100
Message-ID: <54AEA0DA.7080103@gmx.net>
Date: Thu, 08 Jan 2015 16:23:06 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: "secauth@ietf.org" <secauth@ietf.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="mEc32UVuVME80Ux4Trv1GEb5ARG7mc5Q3"
X-Provags-ID: V03:K0:SD15xJ5f8L/a/75jJ2vH4BmTxl9BEPqw9xiqFB76L7ZFOqBPHmR 5Cxo7mdUiqRTrUu46/PFP8d3qvSUYjRDfkodHeDdF/W/0tEXzF4je2d/QdkxLTJqsi9a60V tWxVxAie7hm5czAeG6HYBtvCTTDiR1sOub7lcH3vQOTh+LInbGECAxLHhP19GRvdsvvzKfG z4p2o+8SSKFWU90BnOggg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/secauth/PAzD9xCfKG1XgIsMbqJzoqKOGp8>
Subject: [Secauth] My Summary of the December Conference Call
X-BeenThere: secauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Omni-purpose Network-layer based Secure Authentication and Authorization non-working group discussion list <secauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secauth>, <mailto:secauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secauth/>
List-Post: <mailto:secauth@ietf.org>
List-Help: <mailto:secauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secauth>, <mailto:secauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jan 2015 15:23:13 -0000
Hi all, in December we had a conference call and it clarified many aspects for me. I wanted to post a short summary of what I understood (in an attempt to see whether others got the same impression at the call). Hosnieh explained a model using OpenFlow where the AAA client is actually moved into the cloud. Consequently, there is no need to use RADIUS or Diameter in such a model since the network access authentication messages are just forwarded from the access point to the cloud infrastructure using some tunneling mechanism. Now, there is still a problem with that model since at the end of the protocol dance the access point (who was previously running the AAA client) now has to be informed about the authorization decision. At a minimum it has to get the keys for enabling link layer security. From the discussions on the call I got the impression that this transfer of authorization information from the cloud infrastructure to the access point has not yet been standardized in an OpenFlow alike model. (Note that OpenFlow just served as an example and similar technologies could be used that aim to delegate the execution to some other nodes.) Did others understood the problem description in the same way? If "yes", then the question is * Is this a worthwhile problem to solve? In some sense this could be seen as a competitor to RADIUS and Diameter. * Are we just moving problems around here and not really advancing the state of the art (which might a general question with OpenFlow alike technologies IMHO)? * Is there indeed a standardization gap (or are we just uninformed about the state of the art)? * Is the IETF the right venue to do this type of standardization work? Thoughts? Ciao Hannes
- [Secauth] My Summary of the December Conference C… Hannes Tschofenig
- Re: [Secauth] My Summary of the December Conferen… Hosnieh Rafiee
- Re: [Secauth] My Summary of the December Conferen… Alan DeKok
- Re: [Secauth] My Summary of the December Conferen… Alexandre Petrescu
- Re: [Secauth] My Summary of the December Conferen… Hannes Tschofenig
- Re: [Secauth] My Summary of the December Conferen… Alexandre Petrescu