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

"Hosnieh Rafiee" <ietf@rozanak.com> Wed, 03 December 2014 22:11 UTC

Return-Path: <ietf@rozanak.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 25FD51ACDDE for <secauth@ietfa.amsl.com>; Wed, 3 Dec 2014 14:11:29 -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, 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 wg_R_2EJH_ny for <secauth@ietfa.amsl.com>; Wed, 3 Dec 2014 14:11:22 -0800 (PST)
Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83C61ACD52 for <secauth@ietf.org>; Wed, 3 Dec 2014 14:07:56 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 6EDBE25CA0C6; Wed, 3 Dec 2014 22:07:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at rozanak.com
Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFQq7z5iV--v; Wed, 3 Dec 2014 23:07:23 +0100 (CET)
Received: from kopoli (p5B340A1D.dip0.t-ipconnect.de [91.52.10.29]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id BDBFC25CA066; Wed, 3 Dec 2014 23:07:22 +0100 (CET)
From: Hosnieh Rafiee <ietf@rozanak.com>
To: 'Alan DeKok' <aland@deployingradius.com>
References: <814D0BFB77D95844A01CA29B44CBF8A7A7D2F1@lhreml513-mbb.china.huawei.com> <13B39BFF-50D1-4892-A159-9F8F75BC5C6B@deployingradius.com> <BC5E7A40-8A54-4FEA-9C97-66F194080D74@um.es> <1C6C4744-6FAC-493F-BE48-B0E7821F8A20@deployingradius.com>
In-Reply-To: <1C6C4744-6FAC-493F-BE48-B0E7821F8A20@deployingradius.com>
Date: Wed, 03 Dec 2014 23:07:19 +0100
Message-ID: <00b601d00f45$83033550$89099ff0$@rozanak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIXOWrPTEaPUgM/1gzQCkacbs2gWAJSFHerAkBwjwABDsk1tJvDBxOw
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/Vj2PASIXSjXfjcEAsron8LZ10aA
Cc: secauth@ietf.org
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: Wed, 03 Dec 2014 22:11:30 -0000

>   Yes.  There are multiple companies who act as integrators for these
ISPs.
> There are multiple federations which define how to do different kinds of
> integration.

What if the new network infrastructure changes the role of these companies?
Even the role of many hardware companies might change... and they are aware
of this fact... 
How can you find a role for them in the new infrastructure with SDN/NFV
players? 


> > In fact, what I understand from slide 5 is that, somehow, that trust is
defined
> above southbound API with relationships that allow a user moving from
Hotel
> A to Hotel B.
> 
>   The hotel already authenticates itself to the ISP through DSL.  What is
> needed is an API where the hotel can tell the ISP it's prepared to do
revenue
> sharing for additional users.  If those other users come from another ISP,
then
> the industry standard way to authenticate them is RADIUS.


What is the motivation for hotels to support cross domain authentication?
Or why they should support it? what is the advantage to Hotels?
I might be wrong but I think there is no motivation for a Hotel and it is
only administrative overheads for them. This is why they either would not
care or they are against this. This is of course different for a use case
like a university who are flexible and the use case is not commercial.

I will answer your other questions in your other emails.

Thanks again,
Best,
Hosnieh