Re: [Secauth] (perhaps, wrong wifi access/usage model?) Re: secauth use case - What is next?

[Hosnieh Rafiee <[e-mail]>]

Hi Rene,

Thanks a lot for sharing your comments.

> In my mind, one might as well have the scenario that a user gets access
> to a wifi networks using an initial credential and, to ensure continued
> access - based on his own criteria as perception of delivered services
> (bandwidth speed, etc. "bang for the buck"), may hand out a micro-
> payment to get another lease of life. Upon receipt of this micro-
> payment the access point grants some more "lease of life", depending on
> conversion rate and perhaps congestion-related metrics. The role of
> micropayment settler can be played by Travelocity-like intermediaries,
> who may have contracts with operators of hotspots (or individual home
> owners) who may have capacity to spare. Note that this implies a more
> balanced relationship between station, access point, and infrastructure
> owner than is currently in widespread use. (This is similar to a home
> tapping energy from a neighbor's windmill on the roof, without having
> to go via a centralized utility first.)


> In short: I do not see why operators should have a role of ultimate
> arbiter and spoke in the wheel, as is currently the case. This role may
> very well shift to intermediaries who do transaction processing based
> on small payments. Of course, operators may try and assume this role of
> "transaction man" themselves, but this mapping should not be baked into
> a sound technical design.

I understand your points. I would say, we are talking about the same thing but highlighting different players. In other words, it appears that we are agree on *almost* the scope of the problem but not yet on how handling it (or the requirements). I think at this point the most important thing is that we agree on the general architecture and where and how secauth can influence on such architecture.  

About the suggested main players, I would only say, this is possible if the third party companies produce apps that follows some standards (possible position of secauth) to communicate to vendors' controllers. Then there is no need for SLAs between vendors' controllers but this SLAs is between third parties companies and each vendors (This is another possible place for secauth). Why SLA is because I would consider the case where this customer need to have the same access control as it had in its first network. Moreover, the network devices in new place need to allow this user to bypass them and access some resources via them. No vendors let any external apps to run on its controller without any policy agreements. So, whether or not third party company wants to be in a role of, e.g.,  app and chip producer for this authentication and authorization is what we can decide so that based on this we find the right place for the requirements of standardization. 

In your proposed scenario, standards does not care what's going on between end user and company (for producing this token), but standard (secauth) does care about what's going on between company and vendor (SDN provider). Because the token and policies should be understandable by all SDN controllers. In other word, either one company provide hardware token or software token to end user is out of the scope of secauth but how this token is sent to apps via vendor' infrastructure is in the scope since it should be need to pass through some devices in new network before it is sent to third party company's app for authentication and then the result should be sent back to controller for decision making on policies or allow this user to use this network.

Enclosed picture is how this scenario looks with considering companies as players. 

Why I used operators as main players are because handling this case would be easier since they have already had this contract with vendors and what they need is only to offer a new service to user by either producing this apps or doing nothing and everything is done by vendors and only enable this service. But this is actually not very different from vendors' point of view but might be different from end user's point of view. Therefore, if no operators want to involve in such architecture, we go for the first option and change the main players from operators to third party companies.   




> In the hypothetical scenario I sketched above, the policy and
> authentication mechanisms may be set by the entity that ultimately
> controls money flows, not by the operators whose role may be to pick
> and choose which of these payment/usage schemes to allow on their
> hotspot device (or try and run their own, if they do not like the other
> "currencies" they see out there).

Well, not sure about this because the money flows not always guarantee the security risk that an end user might cause in the vendors' infrastructure.  I would prefer to keep the term "SLA" instead of money flows because SLA also covers the policy requirements. 



> [Note that my scenario is not compatible with Radius schemes, but so be
> it. There is no reason not to embrace more distributed schemes than
> simply more schemes that all flow via huge entities.]

Well, as I said in my last messages. I either do not say we want to use current standards nor do not say we want not to use it. Because this is where the solutions give us opportunities to decide.

> I am not sure what the above means for this "secauth" effort. In the
> context of wifi access, network access is all that counts, so there the
> only thing one needs is a reward for delivered services system, not so
> much a scheme that ties this all together with operators in far away
> places that are much removed from the access point (and a black box
> from user wifi device's perspective). Are there any other use cases
> than wifi access you discussed (e.g., ones where metrics include more
> fine-grained notions of reliability and QoS, and even perhaps trust)?
> 

Secauth does not focus on QoS (but doesn't mean that it is not important but out of scope but secauth care about trust, security and privacy during all the communications. 

We had other use cases such as caring about how we can have a reliable communication at the beginning of communication establishments (trust) and of course, considering device to device authentication (without user interaction) in similar scenario like wifi. 

I hope I could answer your questions/address your comments.

Thanks,
Best,
Hosnieh