[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