Re: [Secauth] Please be volunteer to comment--- Summary of Telco on 19 December 2014

"Hosnieh Rafiee" <ietf@rozanak.com> Mon, 12 January 2015 22:34 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 E6CB51ACDB7 for <secauth@ietfa.amsl.com>; Mon, 12 Jan 2015 14:34:31 -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 bba072424aMA for <secauth@ietfa.amsl.com>; Mon, 12 Jan 2015 14:34:27 -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 1085C1ACD43 for <secauth@ietf.org>; Mon, 12 Jan 2015 14:34:26 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 8780225CA235; Mon, 12 Jan 2015 22:34:23 +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 5W8PEs9RB4QS; Mon, 12 Jan 2015 23:33:51 +0100 (CET)
Received: from kopoli (p20030061E933F2E4D83984A0888BBBC7.dip0.t-ipconnect.de [IPv6:2003:61:e933:f2e4:d839:84a0:888b:bbc7]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id CB16A25CA0DE; Mon, 12 Jan 2015 23:33:50 +0100 (CET)
From: Hosnieh Rafiee <ietf@rozanak.com>
To: 'Alan DeKok' <aland@deployingradius.com>
References: <814D0BFB77D95844A01CA29B44CBF8A7014D9FD0@lhreml504-mbs.china.huawei.com> <324DD2C5-1C94-4F4A-9F6B-2919235DC78F@deployingradius.com>
In-Reply-To: <324DD2C5-1C94-4F4A-9F6B-2919235DC78F@deployingradius.com>
Date: Mon, 12 Jan 2015 23:33:50 +0100
Message-ID: <00dc01d02eb7$d73ce710$85b6b530$@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: AQHFYy3tmsjOkjaYj5/oIbZd2wZFPQE7ghhAnMiu/hA=
Content-Language: en-us
Archived-At: <http://mailarchive.ietf.org/arch/msg/secauth/gP7akXYnc7xGXpbvnimSX_2NU84>
Cc: secauth@ietf.org
Subject: Re: [Secauth] Please be volunteer to comment--- Summary of Telco on 19 December 2014
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: Mon, 12 Jan 2015 22:34:32 -0000

Hi Alan,


Thanks a lot for your comments.  Please find mine inline...

> > <secauth_SDN architecture_8.1.2015.pdf>
> 
>   I have some comments on the slides.
> 
> Page 2:
> 
> * Authentication of a device/apps/service (mobile phone, etc.) to 
> another service/virtual device
> 
>   That statement is about the high-level process.  It should instead 
> describe what the device has, and what it needs.

Thanks. You are right I have to clearly specify the device. The device can
be either a network element (the devices such as router, switch, etc.) or
any intermediate systems.

> i.e. RADIUS is about giving network access to devices which don't have 
> network access

Do you mean a device or an end system (which represents a user)? 

> i.e. OAuth is about authenticating connections to a web service

 I might be wrong, but, IMHO, oauth is authorization protocol and it
authorizes a user. However, other protocol can assist it for authentication.

> Page 3:
> 
>   The table doesn't look right to me.  AAA protocols do cross-domain 
> authentication today.  As does OAuth for app authentication.

I would refer you to the community that are implementing Oauth. Your
statement doesn't look right to me. 

< http://oauth.net/articles/authentication/ >  

>   The table also focusses on the *rest* of the network,  and misses 
> the device.  Once you know the device constraints, your choice of 
> authentication protocol is very limited.

My discussion is about (I wouldn't say it is new) virtual network and SDN
solution concepts. The devices are completely software, the developer of
this software can include any capabilities to it. 



> e.g. devices uses PPP (or EAP to authenticate when they have no 
> network connection.  The authentication credentials go over RADIUS to 
> an authentication server.


> e.g. devices use HTTPS to authenticate to a particular web application 
> when they already have a complete network connection.

The device needs first to be authenticated before being able to send any
information to their network control. This is of course depends on the SDN
architecture. If the main decision making part is not on forwarder device,
They cannot communicate with any app on data center (that are their
authenticator app) before they can be authenticated in their network
control. After this authentication, the app that supports user
authentication can now try to communicate with this device. 

I am thinking about such levels of authentication and authorizations:  
- device authentication to its controller (that is in our scenario hotspot)
- device authorization
- app authentication (the app that handles user authentication)
- app authorization (to access and communicate to device)
- user authentication (communication between app and end system (user))
- user authorization to access the network based on its policy
(authorization offered by both app and controller to this user)

I do not see many similarities to current networks to say we do not need any
new protocol. IMHO, there are some intermediate authentication and
authorization that without them, this communication cannot be happened and
no communication to RADIUS app can be happened either and RADIUS app cannot
authorize any service without the permission from network controller. These
are the real differences.

> 
> Page 4
> 
>   The big X in the upper right side is incorrect.  ISPs already use 
> RADIUS for this type of interconnection.

>   What I think is really happening is that the user shouldn't have to 
> log in again in hotspot B domain.  Authentication should just happen 
> automatically.

How? This is what we are focusing on to solve such scenario with future
network solution. In other word, considering such solution and consider all
requirements for future network. Of course, I would not say it is a far
future.

 
>   This cannot be done today with existing hotspots, because they 
> present a captive portal web page for authentication.  In order for 
> authentication to happen automatically, the entire hotspot 
> infrastructure would have to change.  OR, each device would require a 
> smart client which automatically logs them in (e.g. hotspot 2.0)

Please think about SDN solution and not what you can see as a network and
the constraints that you can see at this point. Does anyone has any
suggestion that how I can show you this? 
 Secauth wants to be a protocol in future network solution and we would like
to consider such scenarios while the vendors are working on the architecture
and deployments of SDN solutions. Of course, I would say, in a blink, we
have to expect such changes because of hard efforts which are happening in
virtualization deployments. 

>   That client MAY also need to remember cross-session information.  e.g.
> "I used to be in hotspot A domain with access Y, and I want the same 
> access Y in hotspot B domain".

Maybe but this is the client side of a protocol that should handle all the
above mention authentication and authorizations and there needs to be
coordination with the controller side of that so that the policy can be
applied easily for any new location of a user.


> Page 5:
> 
>   My question is how does a device communicate with an SDN controller?
> That issue isn't addressed here.  The device may not know the SDN 
> controller exists.  So does the device communicate by ethernet 
> broadcast?  Via IP communication to a special address?  It's a big 
> problem.

The same way one configures a home router to access to the network, this can
also happen. But the differences can be that a part of configuration is in
forwarder device (physical hotspot) and another part is on data centers
where the controller exists. Some of the network devices are easily
upgradable to accept similar structure like openflows (REST) and some are
not. The one that are upgradable, does not need to be replaced. Only the
upgrade of firmware can solve the problem because of software based nature
of this future network and possible compatibility that it can offers. 
Most recent devices supports openflow or upgradable.

But only the problem is that openflow authentication is still a concern
because of policy, authorization and several other reasons. Moreover,
openflow doesn't carry user authentication. Refer you to my message to
Hannes, there are some research papers and experimental implementation of
this combination but no standard. So, why not to consider secauth as that?


>   And why would the SDN controller talk to the device?  It's a random 
> device.  It's unknown, and untrusted.  Any communication channel 
> between the SDN controller and device MUST be very simple and very 
> limited.

I do not think any operators let an unknown device to run on their network
infrastructure or no vendors let any unknown device to send request to their
network controller. It is, of course, not an unknown device but a combined
protocol can solve the authentication and authorization of this device (that
in our scenario hotspot is our device). 

>   e.g. 802.1X and EAP.  The WiFi access point just shuttles ethernet 
> frames between the client and the RADIUS server.  The WiFi access 
> point (for the most part) doesn't even look at the contents of the 
> ethernet frames.  So there's no way for a rogue device to attack the AP.

This now cannot be happened directly if hotspot is only the forwarder
device. The levels I explained earlier as authentication and authorization
needs to happen.

>   If the communication was instead TCP/IP based, that opens up a 
> *huge* attack surface.

Most communication for future network solution is based on REST which is in
application layer.

> Page 6:
> 
>   I'd suggest looking at AAA roaming deployments for how they do 
> authorization across multiple authentication domains.  They do *not* 
> have shared devices.  Everyone is very clear that they have their 
> private devices, and their own policies apply.

As I explained before, I think before we see these changes in our common
networks, these changes will happen in cell phone networks.

>   As the access devices become simpler, the incentive to "own" one 
> becomes less.  So sharing is more likely.  But then the devices become 
> less trustworthy.  Instead of being trusted as part of a network 
> access system, the SDN controllers could become untrusted, just like 
> end-user devices today.  That issue should be addressed, I think.

In one case that is true, but this depends on how the traffic are handled in
these shared devices. But sharing is inevitable since virtualization
techniques is all about sharing. However, these sharing might be only on
edge devices due to many security or traffic controls. 


>   There are big differences between existing roaming situations and SDN.
> When a roaming user connects to a visited network, SDN can be used to 
> "extrude" his home network to the visited location.  This means that 
> authorization policies will be applied by the home network, instead of 
> the visited network.  The visited network may still apply over-all 
> bandwidth and data transfer limits, but that is much simpler than 
> trying to exchange massive amounts of authorization information.

What you say is similar to mobile IPv6 or mobile IP, This scenario is not
scalable. The reason of using SDN is because of having scalability. When
home network and foreign network controller are both somewhere on data
centers, it is even easier for the end system(user) to send its new
authentication token to its new place. Everything is handled easier between
the two controllers and user only submits its authentication token
automatically when join to new network. 

>   e.g. with SDN, the concept of "visited" network largely goes away.  
> A user will authenticate to a visited network, but all traffic / 
> authorization after that will appear (via SDN) as if it's done on the 
> home network.
>   Is this what SECAUTH is about?  So far I haven't seen a clear 
> statement.

Yes. This is exactly what I tried to explain. Everything will happens easier
not harder. The purpose of SDN is NOT to make the network management harder.
But the purpose is to reduce OpEX and  CapEx, Network flexibility and
dynamicity and increase the scalability. 

> Page 8:
> 
>   * User authentication
> 
>   I think the text here assumes a certain architecture, without 
> describing it.  I suggest looking at WiFi networks and RADIUS to see 
> how they solve this problem today.

Yes, I presume the common architecture used in most SDN architecture that is
having 5 main elements -- applications, control plane, data plane and
management plane and the interfaces between them. Such as app to controller
is northbound interface, controller to controller (east and west
interfaces), controller to data plane ( southbound interface) and management
to other planes might also considered as east and west.
I have checked many RADIUS architecture. It cannot answer the requirements
here. There are some missing parts that RADIUS cannot fill these missing
part alone. As I explained before, I do not ignore that they might be good
but only as a user authentication but not when there is a relationship
between app authentication to controller and user authentication and the
policy must be applied for the user after this authentication. Before a user
can send any token to the RADIUS app or whatsoever, the device needs to be
authenticated and authorized in its controller. 

>   In summary, there are three parties.  The end user / device.  The 
> access controller (WiFi AP, 3G cell, SDN box, etc.).  And the 
> authentication server.  The end user trusts the authentication server.
> The authentication server trusts the access controller (and vice versa).
> But the end user doesn't trust the access controller.  And the access 
> controller doesn't trust the end user.

No there are more as we are seeing this in data centers and not as a box. So
SDN solution is not a box. You cannot buy it like a router box. It is only a
software with abstraction levels. i.e., everything is transparent for end
user and each system or user will only receive its requirements and do not
need to know what is going on behind it.

>   The authentication problem is then how do we get the end user and 
> access controller to trust each other?  Once trust is established, the 
> access controller will let the user onto the network.


So IMHO, at least we have these components:
- end user (end system)
- forwarder device (access points)
- network control (decision maker and apply policy to all nodes in the
network)
- authentication apps (you can call it authentication server but this is
virtual component not a physical box)
- interfaces and protocols that needs to work between end system and
forwarder, forwarder and controller, controller and app, controller and
controller



>   The current way to do this is via a *very* simple protocol between 
> the end user and access controller.  e.g. EAP, as described above.

Again this is of course not possible as I explained above.

> 
>   My concern with the text here is that it sounds like the access 
> controller has complex communication with the end user.  That is 
> something which should be avoided as much as possible.

Not complex but there are levels of authentication and authorization due to
changes in network infrastructure and due to having two to many operators
using the same SDN solution but there might be different domains and
isolation but again this doesn't decrease these levels of authentications.

> * App authentication
> 
>   I'm unclear as to how an application on a device can have difference 
> network access than the device it's on.  Is this authorizing 
> particular TCP flows?

Yes, it can be something like that. For example, you are using VoIP in your
first network and you want to have the same on second network. But by
default second network closed VoIP because they do not offer such service.
But you are exception in this network because you have already paid this
service in first network and the SLA between controllers should solve this
problem easily and let you have the same access control as you had in the
first network or as similar as possible. (this is of course just an example
but there might be better examples and use cases)

> * Controller authentication
> 
>   I think that should be outside of the scope of secauth.  The 
> requirements for authenticating untrusted end-user devices are very 
> different than for authenticating trusted network access devices.

I would say there are two different use case here:
- trusted users: this user can access any hotspot that supports SDN
solution.
- arbitrary user (can be untrusted): IMO untrusted user can only access to
open hotspots but easier with SDN solution
When a user establishes a connection to one hotspot, it supposed to provide
some information. If this information are gathered through the real
contract, then the user is trusted. but if it supposed to be an arbitary
user who joined a free hotspot, then there might be some restriction in its
visited network too. Only a few hotspot might answer to its request because
they do not want to offer their service for free. But in the first case, the
user who has any contract with a place who offered it a service for the
first time, it can continue using this service wherever it goes without any
restrictions. This can also come with home internet contract. I agree with
you that the requirement is different. But the differences is not as much as
we need to handle it via different protocol because it is only when the
authorization happens.  In other word, it only uses different policy with
known user and with unknown user that can be again handled via SDN solution
by sending different tokens. 

>   Controllers will mediate network access for end-user devices.  As a 
> result, they are by definition much more trusted than end user devices.

Again I agree. But only the SLA is different and there is one less level of
authentication is needed. In other word, since the nature of SDN is software
concepts, you can consider the communication of two controllers similar to
communication of a priority app with the controller. 

In this case, there is no need for user authentication but only app
authentication is enough but the authentication resources might be in
different place and implemented inside the controller and not accessible by
any app requests because of the security. But there can use the same way for
authentication but only handling different labels for controller
information. 


> * Device authentication
> 
>   The same comments apply here.
> 
> Use case 2: verification of SIP device
> 
>   It is hard to propagate authorization information to many devices in 
> the network.  If the user doesn't make a SIP call, then it's 
> inefficient to provision all of the SIP proxies.

I didn't understand your statement. IMO, this can be done during the call.
Not sure what is not possible. 

I hope I could explain and answer your concerns. If there is any more
concern please share it here.

Any thoughts are welcomed. 

Thanks again,
Best,
Hosnieh