Re: [Secauth] My Summary of the December Conference Call

Hosnieh Rafiee <hosnieh.rafiee@huawei.com> Fri, 09 January 2015 09:50 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 9AA171A8730 for <secauth@ietfa.amsl.com>; Fri, 9 Jan 2015 01:50:02 -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 wDmdHyKZ56oj for <secauth@ietfa.amsl.com>; Fri, 9 Jan 2015 01:49:59 -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 387411A870B for <secauth@ietf.org>; Fri, 9 Jan 2015 01:49:59 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BRA92101; Fri, 09 Jan 2015 09:49:55 +0000 (GMT)
Received: from LHREML504-MBS.china.huawei.com ([169.254.11.10]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Fri, 9 Jan 2015 09:49:52 +0000
From: Hosnieh Rafiee <hosnieh.rafiee@huawei.com>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Thread-Topic: [Secauth] My Summary of the December Conference Call
Thread-Index: AQHQK1cdJKqQUOL0KEaP2ahF52xIh5y3fO2w
Date: Fri, 09 Jan 2015 09:49:51 +0000
Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7014DA7CD@lhreml504-mbs.china.huawei.com>
References: <54AEA0DA.7080103@gmx.net>
In-Reply-To: <54AEA0DA.7080103@gmx.net>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.221.82.195]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/secauth/Ae_QF-xz4QIo-iptDgCQ3zl_B0Y>
Cc: "secauth@ietf.org" <secauth@ietf.org>
Subject: Re: [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: Fri, 09 Jan 2015 09:50:02 -0000

Hi Hannes,

Thanks a lot for sharing your opinion. 


I am just trying to answer your questions and clarify my concerns and what I think is missing here. 

>  * Is this a worthwhile problem to solve? In some sense this could be 
> seen as a competitor to RADIUS and Diameter.

- IMO, this is true that RADIUS and other authentication protocols are working well for user authentication in current network but they were designed for not isolated network islands. There needs to consider redesign of such protocols to fit to new scenarios. They also doesn't support the application/device authentication. My question is that what protocol available to combine app authentication and authorization with user authentication? I refer everyone to my last slides enclosed to summary message. I categorized the current approaches and what I think is missing in the SDN solution architecture.

Let me give you an example, before considering SDN solution, each network could have RADIUS server and configure some clients to access network remotely or access a network via wireless, etc. The  servers and all components were in the same organizational domains but not in different organizational domains. This is , of course, not complete but it worked. For example, for cell phone networks, roaming was possible and hand over was done with some SLA exchange. They weren't supposed to be any shared virtual devices. The user who supposed to be supported in other network, was clearly defined in the new network. They might follow the same way to support their users or they might encounter the same problem when they suppose to run on SDN solution that might need to support several operators at the same time. 

In any case, the scenario that we are talking is not only cell phone networks and hand over in such networks but internet and internet resources. There might be some similar requirements as we need to consider for cell phone networks when using SDN solution. But there are also some new requirements. 

In other word, it is not only how user needs to be authenticated and assign the policies for this user but also there are new players and entities that need to be considered during the authentication and authorization because of shared network resources (among several apps) and shared network controller(s) (among some operators).

The nature of these resources are also different because everything supposed to be software based and we also need to consider the authentication of these software entities to their controllers as well as user authentication. In other word, different levels of authentication and authorization. But what is available for this solution? 
We, of course, have a language that is called REST and many communities considered it as a good way for carrying signaling information but since it is not standard, we have different open source implementations that each supports different structures. So , to run something on vendors' controller, one need to contact the vendor and ask "what plugin do you support that we can write our app based on that?". This is where I think the standard is missing so that the technical information are exchanged via  a standard protocol and only none technical part are exchanged via the paper works. I hope it is clear now.   
 
Some examples of new consideration are, virtual devices that added to the network in run time since SDN considered to be a scalable solution and authentication and authorization of this new vdevices, the integrity of user access control with network policy, etc. and also considering other factors such as performance, etc. 


>  * 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)?

- Openflow or other southbound protocols are used for propagating the signaling information on devices but they do nothing with user authentication and authorization and they do not carry such information.

IMHO, something is missing in the integration of network policy and user policy. I think Vendors deal with network policy while operators or third party companies will deal with user policy. But there might be a need of integration of these policy which I see nothing is available.

There are some research papers to combine authentication mechanisms with openflow but I still did not see any real standard. ONF that works on southbound doesn't support such scenario.
In other word, it is only research and probably a few experimental implementation but not yet standard.

Openflow authentication is also not a solved problem. It is still a concern...

>  * Is there indeed a standardization gap (or are we just uninformed 
> about the state of the art)?

IMHO, yes

> 
>  * Is the IETF the right venue to do this type of standardization work?

Maybe 1 or 2 years ago, IETF wasn't a right place for that but I think there have been a lot of changes at IETF and I can see a lot of efforts in different working groups on virtualization, NFV and also some new mailinglist on SDN (I haven't still considered SDN and NFV RG)


Any thought?

Thanks again,
Best,
Hosnieh