[Secauth] secauth use case - What is next?

Hosnieh Rafiee <hosnieh.rafiee@huawei.com> Wed, 03 December 2014 16:59 UTC

Return-Path: <hosnieh.rafiee@huawei.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 C346E1A6F30 for <secauth@ietfa.amsl.com>; Wed, 3 Dec 2014 08:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Jbg1CmumdtqV for <secauth@ietfa.amsl.com>; Wed, 3 Dec 2014 08:59:22 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFEC1A6EE7 for <secauth@ietf.org>; Wed, 3 Dec 2014 08:59:20 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPN54999; Wed, 03 Dec 2014 16:59:18 +0000 (GMT)
Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 3 Dec 2014 16:59:16 +0000
From: Hosnieh Rafiee <hosnieh.rafiee@huawei.com>
To: "secauth@ietf.org" <secauth@ietf.org>
Thread-Topic: secauth use case - What is next?
Thread-Index: AdAPGnVPQy97ch4/Sr2Fm7C0KDV6Dg==
Date: Wed, 03 Dec 2014 16:59:15 +0000
Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A7D2F1@lhreml513-mbb.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.221.82.91]
Content-Type: multipart/mixed; boundary="_002_814D0BFB77D95844A01CA29B44CBF8A7A7D2F1lhreml513mbbchina_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/sFL67RswnaP73zXoA8nmkF_RrEk
Subject: [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 16:59:25 -0000

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. 

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

@Michael: I think we need to change the actor so that we can simplify the deployments which is the important point for IETF. I agree that ISPs are important actors.

In other words, my main actors are : SDN providers (industries), Operators (O2, Telekom, etc.).  My side actors are: end users, admins of hotels, resellers. 

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. 
I do not want to tell the advantages of the support of such work for operators. I would like first to see your comments. Then if I see no one spelled it out, then I would do it. 

Why the main actors should not be hotel, etc.? 
- They mostly do not have technical people to configure this and this is overhead for them
- This is not their main issue as they suppose to provide a temporary service

Why the main actors should not be an end user?
- It cannot influence the whole process

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.  Of course, we can use some groups like Oauth as a base and extend it to fit to our own use case.
3- seamless authentication and authorization (this is especially true for sensors or small devices without keyboard to set the authentication)
4- Reliability in first time communication that was the other use case for secauth.
5- user's Privacy in case of using shared resources or whatsoever. 

Please share your inputs.

Thanks,
Best,
Hosnieh