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

[Alan DeKok <[e-mail]>]

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