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

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 8 Jan 2015 13:28:49 +0000

Folks,

Happy new year! I hope you start a good year and enjoyed your new year holiday and ready to activate the group again :-)

Here is the summary of the meeting
- Presentation of available standards, secauth use cases, its possible scope,  
- To remove use case 4 related to authentication of IoT to cloud system and only focus on SDN related solution
- Discussion about adding the exact place (a picture or slide) to show where a protocol is missing and the exact scope of secauth.

Enclosed you can find the revision of slides used for the telco discussion on 19 December to consider the comments received during telco. Again thanks Alex, Rafa, Gabriel, Alan for sharing their opinions. 

Comments are welcomed. If you see something is unclear on slide and need any discussion just share it on the mailinglist.

Thanks,
Best,
Hosnieh

---

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Jan 2015 10:28:01 -0500

On Jan 8, 2015, at 8:28 AM, Hosnieh Rafiee <[email-masked]> wrote:
> <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.

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

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

  Keeping the discussion grounded means it’s easier to understand.

Page 3:

  The table doesn’t look right to me.  AAA protocols do cross-domain authentication today.  As does OAuth for app 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.

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.

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.

  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)

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

  When there’s no cross-session information, the device is limited to authenticating from scratch in hotspot B domain.  i.e. the two authentications are completely independent, and there’s no way to coordinate them.  This is what happens today, and it seems to work reasonably well for a large set of situations.

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.

  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.

  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.

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

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

  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.

  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.

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.

  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.

  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.

  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.

  Once the user is authenticated, the authentication server tells the access controller to trust the user.  The authentication server tells the user to trust the access controller.  And everything is fine.

  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.

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

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

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

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

  Alan DeKok.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Mon, 12 Jan 2015 23:33:50 +0100

Hi Alan,

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

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

>   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 

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)

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

>   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

---

From: Gabriel López <[email-masked]>
Date: Tue, 13 Jan 2015 10:24:20 +0100

Hi Hosnieh,

sorry for the late response ...

El 08/01/15 a las 14:28, Hosnieh Rafiee escribió:

Folks,

One of my concerns, probably a little one, but probably not, is that
following your assumptions in #5 it seems (IMHO) that you are
describing something more related with NFV (Network Function
Virtualization) than with SDN. I means, it seems to me that you are
trying to virtualize some kind of security function (authentication)
rather than a policy-driven network behaviour.

SDNs controllers (including and beyond OpenFlow) runs over L2/L3
network devices, analyse incoming network traffic, take a decision
about this traffic and enforce the decision into the network device,
the traffic goes on or it is denied. Sometimes those controllers
need the help for other services (Firewalls, Load balancers, IDS,
etc), and then invoke the upper layer to use them.

Following your slides, your clients (APs) needs to invoke to an
authentication service, which seems to be virtualized, the service
takes an authentication decision and responds Yes or Not. The
traffic does not go on or is denied, the service is the traffic's
target. As said before, IMHO (and I can be probable wrong), this
behaviour is more related with NFV than with SDNs.

Said that, On one hand, I agree with Alan in the way that the target
scenario (without taking into account the use or not of SDNs) seems
that could be solved making use of current technologies (note that
I'm not saying it is not an interesting use case, on the contrary).

On the other hand, if the objective is to solve this use case but
making use of new technologies (i.e. SDNs) it would be nice to
analyse the requirements driving this objective. I mean, we can not
decide to use SDNs only because it will be the technology of the
future.

Use case 2:

"All SIP proxy needs to be configured in order to authenticate
Alice’s phone to connect to another person". AFAIK that's not true.
Only the home SIP proxy authenticates Alice.

"since these SIP proxy servers are all also virtualized
components" --> NFV

Where SDNs could help in this scenario is in the management and
enforcement of the required QoS parameters into the network devices
for the media traffic.

Use case 3:

Sorry, I do not see how this use case is related with the other
ones.

In summary, I think the use case is good enough to work on it,
but I'm not sure about the standardization requirements.

Best regards, Gabi.

Thanks,
Best,
Hosnieh

_______________________________________________
Secauth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secauth

--
--------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 13 Jan 2015 11:45:45 +0100

Hi Hosnieh:

Let me focus in the use case 1 to provide my comments.

The communication between SDN controllers (east-west interface) may be based in several protocols: RADIUS and Diameter. Or for example JSON (that is the case of trust routers https://tools.ietf.org/html/draft-mrw-abfab-trust-router-02 ). For Diameter, most probably there is no Diameter application of doing that but I am not sure. What it is true is 3g/4g operators have already defined ways of doing roaming so they may exchange SLA information in some way. It would be worthy asking them. 

For the case of southbound API, and the use case 1, I may use CAPWAP (http://tools.ietf.org/html/rfc5415). In fact, it seems others have thought about it https://wiki.opendaylight.org/view/Project_Proposals:CAPWAP. By the way, for the fast handoff and security between access points, IEEE 802.21a may be used since it allows a centralized way of doing authentication that (http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6704478) . So the PoS could be part of the SDN controller.

Another alternative, as well, it is to extend OpenFlow to provide this kind of function (e.g. distribution security policies and cryptographic material to the switch). Unfortunately, OpenFlow is not standardized in the IETF. For example, we are considering here at the University a model where IKE is in the SDN controller and IPsec in the switch. Now, how do we enforce IPsec security policies and cryptographic keys to the "switch"? Most probably an extension of OpenFlow would be the best and easier. But again that extension should be discussed in other place.

Best Regards.

El 08/01/2015, a las 14:28, Hosnieh Rafiee <[email-masked]> escribió:

> <secauth_SDN architecture_8.1.2015.pdf>_______________________________________________
> Secauth mailing list
> [email-masked]

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------