Re: [Secauth] Can we also be protected against such attacks?

[Hosnieh Rafiee <[e-mail]>]

Hi Alex,

> 
> When I read this article I wonder when was the last time I clicked on a
> linkedin button, whether Symantec covers the Regin risk, and try to
> remember whether this person in Belgium invented the AES candidate or
> is it somebody else.
> 
> But, what is an open authentication domain?


By considering the case where each hotspot might be under the control of different administrative domains but they would need to open their service to end-users, then such phrase might cover the meaning or I might use a bad phrase for that. My main message is that, I guess with openness (that we call it automation of interdomain and crossdomain authentication and authorization), the risk of similar attacks might increase since an infected node in a new network might increase a risk of other nodes' infection in its visited network. 


There are some thoughts about this scenario

The use case for secauth that I am thinking about is not only a simple cross domain authentication but also considering a case where the management/controlling and interfaces of the physical devices are somewhere on datacenters except the physical layer located, e.g., at the hotel or airport (physical hotspot). IMO, This is actually where we are going and there is good efforts by different groups of manufactures/vendors. I guess this would change internet architectures since the administrative domains are virtually controlled. 
One example is that, there is one operator who offered its service to hotel x, y and z. this is true that the customers can control their own devices via their user interface placed somewhere on cloud but operator has higher privilege on this service and can set this inter domain authentication agreement for all these hotels by easily asking them whether they want to support this feature (because of these advantages), if yes, they can set it as a default settings of their customers (hotel x, hotel y, hotel z)

Now, we want to extend this to different operators (cross domain authentication). So, the client first time register with first hotel and in each new hotel, the automatically sent its request with its token (that might be kept somewhere on cloud that is accessible to all operators) controller and handled in a centralized controller/s. We need a way of communication between controllers from different vendors so that this cross domain authentication can happen. In other word, in my opinion the focus of secauth should not be only end user who request this service but vendors who can enable this service. In other word, we need transparency to offer such service to end-users.

I hope I could clearly explain my thoughts.

Any thoughts?

Thanks,
Best,
Hosnieh



Therefore, it is not only 

1-