Re: [Secauth] secauth use case - What is next?

["Hosnieh Rafiee" <[e-mail]>]

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