Re: [Secauth] secauth use case - What is next?

Alexandre Petrescu <alexandre.petrescu@gmail.com> Thu, 04 December 2014 17:52 UTC

Return-Path: <alexandre.petrescu@gmail.com>
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 34BD21A0373 for <secauth@ietfa.amsl.com>; Thu, 4 Dec 2014 09:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 mSkeoImuutE5 for <secauth@ietfa.amsl.com>; Thu, 4 Dec 2014 09:52:00 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50151A026F for <secauth@ietf.org>; Thu, 4 Dec 2014 09:51:59 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id sB4HpvaA002459 for <secauth@ietf.org>; Thu, 4 Dec 2014 18:51:57 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 58129207F3E for <secauth@ietf.org>; Thu, 4 Dec 2014 18:52:00 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 50306207F3D for <secauth@ietf.org>; Thu, 4 Dec 2014 18:52:00 +0100 (CET)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id sB4HpXOT030437 for <secauth@ietf.org>; Thu, 4 Dec 2014 18:51:57 +0100
Message-ID: <54809F25.1040005@gmail.com>
Date: Thu, 04 Dec 2014 18:51:33 +0100
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: secauth@ietf.org
References: <814D0BFB77D95844A01CA29B44CBF8A7A7D2F1@lhreml513-mbb.china.huawei.com> <13B39BFF-50D1-4892-A159-9F8F75BC5C6B@deployingradius.com>
In-Reply-To: <13B39BFF-50D1-4892-A159-9F8F75BC5C6B@deployingradius.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/wgUZ14cE-hSMzGqGJeuatmoy_m0
Subject: Re: [Secauth] secauth use case - What is next?
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, 04 Dec 2014 17:52:02 -0000


Le 03/12/2014 19:44, Alan DeKok a écrit :
> On Dec 3, 2014, at 11:59 AM, Hosnieh Rafiee
> <hosnieh.rafiee@huawei.com> wrote:
>
>> Folks, I have created some slides to explain where secauth can work
>> in this specific scenario that is hotspot entities' authentication
>> and authorization. I reviewed all previous comments.
>
> They explain the situation well.
>
>> @Paul:
>>> Other forums are working on the problem:
>>> https://www.wi-fi.org/passpoint-release-2-operator-best-practices-for-aaa-interface-deployment-v200
>>
>>>
I have checked it. This is true that they want to have similar function, 
but their main actor is end user. I am thinking about fully transparency 
for end-user and also Hotels or hotspot domain admins.
>
> I’ve spent time working at a WiFi inter-connect provider.
> Interconnections are *hard*.  They require human involvement.  The
> protocols are easy.  RADIUS, IPSec, etc.  The hard part is that
> everyone’s business methods, billing, etc. are different.  The
> interconnect providers do significant work to mangle each packet to /
> from disparate ISPs.
>
>> Is there any operators in this group to share the opinions from
>> operators' point of view? Telekom? O2? Vodafone? I only can discuss
>> this from industrial point of view.
>
> The operators tend to not be involved in the IETF.  I spend a fair
> amount of time talking to them, though.
>
>> Where secauth can work: 1- If more than one industries,
>> communication between SDN controllers.(interoperability of two
>> different SDN providers) 2- The whole process for interdomain and
>> cross domain authentication & probably authorization (if any
>> specific policy should be applied in new network) including
>> considering shared resources (for tokens and policies, etc.).
>> Current standards like RADIUS, etc. cannot provide cross domain
>> authentication.
>
> I have no idea what that means.  RADIUS is *widely* used on
> cross-domain authentication.  I can say without exaggeration that
> outside of 3G, it’s the *only* protocol used for cross-domain
> authentication.
>
> Eduroam is widely used.  IETF WGs like Abfab are standardizing
> cross-domain authentication, where the domains require no previous
> coordination to communicate.  They only require a common CA, which
> shows that both domains are part of the same roaming consortium.
>
>> 3- seamless authentication and authorization (this is especially
>> true for sensors or small devices without keyboard to set the
>> authentication)
>
> These scenarios are widely deployed today.  e.g. medical devices
> which send telemetry data back to a central monitoring system.  The
> devices use EAP for authentication, and RADIUS for cross-domain
> authentication.

Ok when EAP is used, but how about public hotspots managed by web portal 
where users need to fill in forms?

It may be easy to connect my laptop to that airport lounge hotspot, but 
I doubt my future watch will connect as easy.

Alex

>
> Alan DeKok.
>
> _______________________________________________ Secauth mailing list
> Secauth@ietf.org https://www.ietf.org/mailman/listinfo/secauth
>