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

Alan DeKok <aland@deployingradius.com> Wed, 03 December 2014 21:35 UTC

Return-Path: <aland@deployingradius.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 5B4E11AC528 for <secauth@ietfa.amsl.com>; Wed, 3 Dec 2014 13:35:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 LeEHcMQr0SCm for <secauth@ietfa.amsl.com>; Wed, 3 Dec 2014 13:35:21 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5468C1AC445 for <secauth@ietf.org>; Wed, 3 Dec 2014 13:35:02 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id BA535224042D; Wed, 3 Dec 2014 22:35:01 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EaMXI0C5lUTf; Wed, 3 Dec 2014 22:34:59 +0100 (CET)
Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id CE2E022402E2; Wed, 3 Dec 2014 22:34:58 +0100 (CET)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <BC5E7A40-8A54-4FEA-9C97-66F194080D74@um.es>
Date: Wed, 03 Dec 2014 16:34:57 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C6C4744-6FAC-493F-BE48-B0E7821F8A20@deployingradius.com>
References: <814D0BFB77D95844A01CA29B44CBF8A7A7D2F1@lhreml513-mbb.china.huawei.com> <13B39BFF-50D1-4892-A159-9F8F75BC5C6B@deployingradius.com> <BC5E7A40-8A54-4FEA-9C97-66F194080D74@um.es>
To: Rafa Marin Lopez <rafa@um.es>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/AGeT19zmVyy-H0ldtFhMlp2ZuLw
Cc: Hosnieh Rafiee <hosnieh.rafiee@huawei.com>, "secauth@ietf.org" <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 21:35:24 -0000

On Dec 3, 2014, at 2:41 PM, Rafa Marin Lopez <rafa@um.es> wrote:
> Having said that, regarding the problem statement, if we want the user to access ISP1 and ISP2 , then there must be at some point some source of common trust (e.g. some IdP or entity that ISP1 and ISP2 both trust). For example, ISP1 and ISP2 may belong to a federation though they do not have direct SLAs.  	

  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.

> 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.

  Alan DeKok.