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

[Rene Struik <[e-mail]>]

Dear Hosniee:

Thanks for the slides (I now found them at the bottom of one of your 
emails).

I must say that I think your use case model re different hotspots may be 
too restrictive (my email focuses on that use case).

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.

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

Please note one important point here: technology (esp. security 
technology) is not neutral and can be used to ossify existing business 
interests, by design.

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

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

Best regards, Rene


On 12/3/2014 6:44 PM, Hosnieh Rafiee wrote:
>>> What is the motivation for hotels to support cross domain
> authentication?
>>   I have no idea.  I was referencing your slides.
> But I did not say that we need to change anything on  end users or hotels.
> My first players are industries and the second players are operators. The
> changes are transparent for the first two players (end users and hotels) and
> easy for operators. One time implementation for industries and providers.
> This is why the hotels do not see any changes to be against it or there is
> no extra overheads for hotels.
>   
> I answered your other email the followings...
>
>>> 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.
>>    I'm not clear on what that means.
> I mean...... please for some moments forget about thousands of physical
> switches, routers, firewalls, etc. Just consider some VMs that play a role
> of these physical devices (as it already exists in clouds, e.g. vswitches)
> and if there is also any physical devices for routing information between
> two/many data centers, they are only forwarder devices and the real decision
> for applying rules or policies (e.g. packet filtering) are done in another
> virtual component called controller somewhere in one of these data centers.
> For configuration, there are some apps which provide interfaces but there is
> a restricted authentication and access control because a controller might
> need to control several virtual or physical devices that might belong to
> many different administrative domains.
> Example, you can have an isolated LAN A and LAN B and define the users in
> these two LANS in different RADIUS servers controlled by different
> administrators. You can easily have this physical separation or isolation
> even by some cables. So,  what about this use case where there are big data
> centers around the world and each data centers consists of components of
> several WANs and LANS. Some vswitches might be shared among different
> administrative domains. So the isolation is logical and physical isolation
> might not have its old meaning.
>
> So, each operators in such scenario might have several customers but an
> example feature such as authentication federation is only an app which can
> be accessed by many operators to share some user resources (token,
> policies). So, only operator request to access this federation app for its
> users (this is where the third party companies could play, i.e. producing
> apps). Now, I as an end user have a contract with an ISP.  If my ISP runs on
> this new infrastructure (SDN based and network virtualization), I have an
> option to enable this service when I sign my contract with my ISP. I might
> pay a few euro more to use this service wherever it is supported in a new
> network. Hotels do not need to do anything since the decision are made in
> higher levels and if I do anything wrong, I might be tractable in my main
> ISP where issued me that token. This token plus policy information about my
> use case is stored in a in a shared resources accessible by all controllers
> of different industries. So wherever I go, my client automatically provide
> that token to the hotspot and hotspot forward it to its controller and
> controller decides to let me use the service in new network if my token is
> valid. So hotspot only forwarded that request to its controller. Controller
> makes the decision and verifies this token.
>
> The requirements:
> - high level SLA: An agreement between all industries who want to support
> such scenario for a distributed resource server. (as one industry, we want
> to support this)
> - a common standard to authenticate and authorize user in new network. (here
> you can evaluate current approaches but see which one fits better to this
> scenario and what changes needed to be considered)
> -
>
>
>>    Diameter.  There are hundreds of specifications in 3G, each of which are
>> hundreds of pages long, all defining exchange of SLAs for users.  These
>> exchanges happen *millions* of times a day, every way.  They've been
>> deployed for many years.  There are billions of dollars in equipment sold
>> every year to do exactly this.
> But, what I can see, the 3G and mobile networks are also a part of this
> change. I also think that this happens faster than the goal we are looking
> for in this group or other groups at IETF.So, again I would say it is not a
> solved problem and it is the evolution of new problems. This is why I am
> *suspect* that the same protocols can be used as before or there is a need
> for small or big changes.
>
>>    Abfab is about roaming inside of a consortium.  It's a light version of
> the 3G
>> specs.
> We might come to decision to use any current group as a base to fulfil our
> goals and work on use cases we define here which might be quite different
> than the use cases they have defined or the goal they have defined for their
> groups.
>
>>    Very little.  Sensors can have a list of known networks.  Cell phones do
> this
>> today.  Networks can be configured to allow sensors to roam.  They do this
> will
>> cell phones today.
>>
> You are right about cell phones but what about other kind of sensors such as
> a car which supports a sensor for receiving updated information from
> internet regarding traffic, accidents, etc. but of course moves and have no
> keyboard for configuration during movement.
>
>
>>    It's something I've been working towards for a decade.  My experience
> has
>> been that the authentication interconnect is simple.  RADIUS, Diameter,
> IPSec,
>> whatever.  It's all trivial.  The hard part is the policy exchanges.  How
> do you
>> describe the policies?  Firewall rules?  SAML?  Something else?
> Yes, it can be anything that defines how a user should access and use the
> resources in a network including firewall rules, etc. In other words, safe
> policy that does not cause any security risk in a new network.
> I no longer say that the authentication is simple nor difficult. I only say
> that because of having everything virtualized in a certain infrastructure ,
> the communication of these components does need authentication and applying
> access control policies since the trust is no longer like a physical link
> between two devices but a trusted domain between components. Therefore, I am
> not sure all the current protocols can be used and considered for such this
> network.
> Maybe possible to use them as a base but then extend them to fit to certain
> use case. For example, consider Oauth and consider it in the SDN
> architecture but fit it to a new use case (this is only an example...)
>
> Thanks for the clarification about Eduroam project.
> And thanks for your comments,
> Best,
> Hosnieh
>
>
>   
>
>
> _______________________________________________
> Secauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secauth


-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]