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

"Hosnieh Rafiee" <ietf@rozanak.com> Wed, 03 December 2014 21:12 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 13D321A86E9 for <secauth@ietfa.amsl.com>; Wed, 3 Dec 2014 13:12:22 -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 eI0u2JKl_9OX for <secauth@ietfa.amsl.com>; Wed, 3 Dec 2014 13:12:18 -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 C6BC61A700D for <secauth@ietf.org>; Wed, 3 Dec 2014 13:11:51 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id E5E1825CA0C6; Wed, 3 Dec 2014 21:11:48 +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 BMO2PbwFbA-h; Wed, 3 Dec 2014 22:11:17 +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 CECB525CA066; Wed, 3 Dec 2014 22:11:16 +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>
In-Reply-To: <13B39BFF-50D1-4892-A159-9F8F75BC5C6B@deployingradius.com>
Date: Wed, 03 Dec 2014 22:11:12 +0100
Message-ID: <00b201d00f3d$acc44530$064ccf90$@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/1gzQCkacbs2gWAJSFHerm91TmcA=
Content-Language: en-us
Archived-At: http://mailarchive.ietf.org/arch/msg/secauth/mNUYZiOyw9LOg3QFzerupILRbz4
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 21:12:22 -0000

Hi Alan,

Thanks a lot for sharing your comments. See my comments inline.

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

I understand your concerns completely and I know the difficulty of this
scenario IF and IF we only think about end users and we only want to put all
overloads on operators. Then, there will be no motivation for this. This is
why I suggested the SDN scenario and shared the possible architecture (my
slides in my last message) that you could find in my message.  In other
words, It is so much administrative works if only everything should be done
either by operators or by interfaces between end users and operators (such
as hotels, etc.) but  with SDN scenario the capability are added to the
infrastructure and manageable by operators. Therefore, via management
interfaces, operators need only enable/disable this feature based on the
request of their customers. So, In one hand, it appears that the overhead is
on industries who wants to offer this service or develop such protocols for
communications on data centers, etc. 


>  The operators tend to not be involved in the IETF.  I spend a fair amount
of
> time talking to them, though.

I am not quite sure about what you said since I saw some of them active in
other groups and I think a few of them are a member of this group too.

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

Maybe I also should highlight the trust between two controllers especially
when a user wants to receive the same service in target network under the
control of different industries. In other words, user a used voip in first
network and wants to continue using it in second network. Maybe by default
this service is not enable on firewall in the second network. So there might
be a need to enable this service based on policy for this user (this is of
course an example). In one hand that we talk about this trust, in other
hand, we have to consider a shield controller. This is why, I am also not
sure RADIUS or other approaches will be considered in SDN architecture.
There might be new requirements that is not supported by RADIUS or not
easily handled. Like the example scenario I have explained. 
I agree that in mobile network, such scenario was implemented but mostly it
is only for one Operator. I saw some exceptional cases where, for example, a
user moves from one country to another and operator in source country does
not have coverage, then this user might be registered with a new operator
that has SLA with his operator in source country. But how this SLA
exchanged? How many administrative work it was needed that this happened?
This is maybe the demotivation for operators. Now, how we can simplify this
use case  (of course this time only for internet) ? I do not think  Abfab or
other groups covered this scenario.
We can of course consider other groups as a base of secauth to work on such
specific use cases that depends on what folks think to proceed and work on
such scenario.


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

So, is the assumption the existence of a public CA? In other word, any
network who wants to use this service needs to have a valid certificate? or
it is like trusted anchor?

I do want to skip the use of CA in secauth and find different solution to
provide this trust because of privacy and perhaps security reasons.

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

True, however, I think, it supports a limited scope because
pre-configuration needed for such scenarios. Can you move this sensor
devices to unknown networks that it never supposed to move to that network?
How much efforts is needed to make this happened?

Now what if we consider an automated process that is infrastructural based
and not by the agreements of each single players with each other in this
scenario but the agreements are in higher level?

Thanks,
Best,
Hosnieh