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

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 3 Dec 2014 16:59:15 +0000

Folks,
I have created some slides to explain where secauth can work in this specific scenario that is hotspot entities' authentication and authorization. 
I reviewed all previous comments. 

@Paul:
> Other forums are working on the problem:  https://www.wi-fi.org/passpoint-release-2-operator-best-practices-for-aaa-interface-deployment-v200
I have checked it. This is true that they want to have similar function, but their main actor is end user. I am thinking about fully transparency for end-user and also Hotels or hotspot domain admins. 

@Michael: I think we need to change the actor so that we can simplify the deployments which is the important point for IETF. I agree that ISPs are important actors.

In other words, my main actors are : SDN providers (industries), Operators (O2, Telekom, etc.).  My side actors are: end users, admins of hotels, resellers. 

Is there any operators in this group to share the opinions from operators' point of view? Telekom? O2? Vodafone? I only can discuss this from industrial point of view. 
I do not want to tell the advantages of the support of such work for operators. I would like first to see your comments. Then if I see no one spelled it out, then I would do it. 

Why the main actors should not be hotel, etc.? 
- They mostly do not have technical people to configure this and this is overhead for them
- This is not their main issue as they suppose to provide a temporary service

Why the main actors should not be an end user?
- It cannot influence the whole process

Where secauth can work: 
1- If more than one industries, communication between SDN controllers.(interoperability of two different SDN providers)
2- The whole process for interdomain and cross domain authentication & probably authorization (if any specific policy should be applied in new network) including considering shared resources (for tokens and policies, etc.). Current standards like RADIUS, etc. cannot provide cross domain authentication.  Of course, we can use some groups like Oauth as a base and extend it to fit to our own use case.
3- seamless authentication and authorization (this is especially true for sensors or small devices without keyboard to set the authentication)
4- Reliability in first time communication that was the other use case for secauth.
5- user's Privacy in case of using shared resources or whatsoever. 

Please share your inputs.

Thanks,
Best,
Hosnieh

---

From: Alan DeKok <[email-masked]>
Date: Wed, 3 Dec 2014 13:44:26 -0500

> I reviewed all previous comments. 

 They explain the situation well.

> I have checked it. This is true that they want to have similar function, but their main actor is end user. I am thinking about fully transparency for end-user and also Hotels or hotspot domain admi…

 I’ve spent time working at a WiFi inter-connect provider.  Interconnections are *hard*.  They require human involvement.  The protocols are easy.  RADIUS, IPSec, etc.  The hard part is that everyone’s business methods, billing, etc. are different.  The interconnect providers do significant work to mangle each packet to / from disparate ISPs.

> Is there any operators in this group to share the opinions from operators' point of view? Telekom? O2? Vodafone? I only can discuss this from industrial point of view. 

 The operators tend to not be involved in the IETF.  I spend a fair amount of time talking to them, though.

> 2- The whole process for interdomain and cross domain authentication & probably authorization (if any specific policy should be applied in new network) including considering shared resources (for tokens and policies, etc.). Current standards like RADIUS, etc. cannot provide cross domain authentication.

 I have no idea what that means.  RADIUS is *widely* used on cross-domain authentication.  I can say without exaggeration that outside of 3G, it’s the *only* protocol used for cross-domain authentication.

 Eduroam is widely used.  IETF WGs like Abfab are standardizing cross-domain authentication, where the domains require no previous coordination to communicate.  They only require a common CA, which shows that both domains are part of the same roaming consortium.

> 3- seamless authentication and authorization (this is especially true for sensors or small devices without keyboard to set the authentication)

 These scenarios are widely deployed today.  e.g. medical devices which send telemetry data back to a central monitoring system.  The devices use EAP for authentication, and RADIUS for cross-domain authentication.

 Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 3 Dec 2014 13:45:45 -0500

> I have no idea what that means.  RADIUS is *widely* used on cross-domain authentication.  I can say without exaggeration that outside of 3G, it’s the *only* protocol used for cross-domain authentic…

  Make that “network access” cross-domain authentication.

  If you have network access, things like OAuth are widely used, and are more appropriate.

  Alan DeKok.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 3 Dec 2014 20:41:59 +0100

Hi Hosnieh:

I think the slides reflect the use case better. 

I agree with Alan's points here. The usage of EAP/AAA is important because typical access points already provide that feature. Also AAA is used for cross-domain authentication. As University we are used to the case where students coming from other Universities can access our APs with his credentials in their home institution. Eduroam and AAA-based federation make this possible.

Having said that, regarding the problem statement, if we want the user to access ISP1 and ISP2 , then there must be at some point some source of common trust (e.g. some IdP or entity that ISP1 and ISP2 both trust). For example, ISP1 and ISP2 may belong to a federation though they do not have direct SLAs.  	

In fact, what I understand from slide 5 is that, somehow, that trust is defined above southbound API with relationships that allow a user moving from Hotel A to Hotel B.

Best Regards.

El 03/12/2014, a las 19:44, Alan DeKok <[email-masked]> escribió:

> _______________________________________________
> Secauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secauth

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 3 Dec 2014 22:11:12 +0100

Hi Alan,

Thanks a lot for sharing your comments. See my comments inline.

> > @Paul:
> >> Other forums are working on the problem:  https://www.wi-
> fi.org/passpoint-release-2-operator-best-practices-for-aaa-interface-
> deployment-v200
> > I have checked it. This is true that they want to have similar function,
but
> their main actor is end user. I am thinking about fully transparency for
end-
> user and also Hotels or hotspot domain admins.
> 
>  I've spent time working at a WiFi inter-connect provider.
Interconnections
> are *hard*.  They require human involvement.  The protocols are easy.
> RADIUS, IPSec, etc.  The hard part is that everyone's business methods,
billing,
> etc. are different.  The interconnect providers do significant work to
mangle
> each packet to / from disparate ISPs.

I understand your concerns completely and I know the difficulty of this
scenario IF and IF we only think about end users and we only want to put all
overloads on operators. Then, there will be no motivation for this. This is
why I suggested the SDN scenario and shared the possible architecture (my
slides in my last message) that you could find in my message.  In other
words, It is so much administrative works if only everything should be done
either by operators or by interfaces between end users and operators (such
as hotels, etc.) but  with SDN scenario the capability are added to the
infrastructure and manageable by operators. 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. 

>  The operators tend to not be involved in the IETF.  I spend a fair amount
of
> time talking to them, though.

I am not quite sure about what you said since I saw some of them active in
other groups and I think a few of them are a member of this group too.

> > Where secauth can work:
> > 1- If more than one industries, communication between SDN
> controllers.(interoperability of two different SDN providers)
> > 2- The whole process for interdomain and cross domain authentication &
> probably authorization (if any specific policy should be applied in new
> network) including considering shared resources (for tokens and policies,
> etc.). Current standards like RADIUS, etc. cannot provide cross domain
> authentication.
> 
>  I have no idea what that means.  RADIUS is *widely* used on cross-domain
> authentication.  I can say without exaggeration that outside of 3G, it's
the
> *only* protocol used for cross-domain authentication.

Maybe I also should highlight the trust between two controllers especially
when a user wants to receive the same service in target network under the
control of different industries. In other words, user a used voip in first
network and wants to continue using it in second network. Maybe by default
this service is not enable on firewall in the second network. So there might
be a need to enable this service based on policy for this user (this is of
course an example). In one hand that we talk about this trust, in other
hand, we have to consider a shield controller. This is why, I am also not
sure RADIUS or other approaches will be considered in SDN architecture.
There might be new requirements that is not supported by RADIUS or not
easily handled. Like the example scenario I have explained. 
I agree that in mobile network, such scenario was implemented but mostly it
is only for one Operator. I saw some exceptional cases where, for example, a
user moves from one country to another and operator in source country does
not have coverage, then this user might be registered with a new operator
that has SLA with his operator in source country. But how this SLA
exchanged? How many administrative work it was needed that this happened?
This is maybe the demotivation for operators. Now, how we can simplify this
use case  (of course this time only for internet) ? I do not think  Abfab or
other groups covered this scenario.
We can of course consider other groups as a base of secauth to work on such
specific use cases that depends on what folks think to proceed and work on
such scenario.

>  Eduroam is widely used.  IETF WGs like Abfab are standardizing
cross-domain
> authentication, where the domains require no previous coordination to
> communicate.  They only require a common CA, which shows that both
> domains are part of the same roaming consortium.

So, is the assumption the existence of a public CA? In other word, any
network who wants to use this service needs to have a valid certificate? or
it is like trusted anchor?

I do want to skip the use of CA in secauth and find different solution to
provide this trust because of privacy and perhaps security reasons.

> > 3- seamless authentication and authorization (this is especially true
for
> sensors or small devices without keyboard to set the authentication)
> 
>  These scenarios are widely deployed today.  e.g. medical devices which
send
> telemetry data back to a central monitoring system.  The devices use EAP
for
> authentication, and RADIUS for cross-domain authentication.

True, however, I think, it supports a limited scope because
pre-configuration needed for such scenarios. Can you move this sensor
devices to unknown networks that it never supposed to move to that network?
How much efforts is needed to make this happened?

Now what if we consider an automated process that is infrastructural based
and not by the agreements of each single players with each other in this
scenario but the agreements are in higher level?

Thanks,
Best,
Hosnieh

---

From: Alan DeKok <[email-masked]>
Date: Wed, 3 Dec 2014 16:31:44 -0500

On Dec 3, 2014, at 4:11 PM, Hosnieh Rafiee <[email-masked]> wrote:
>  In other
> infrastructure and manageable by operators.

  That works in certain narrowly defined scenarios.

> Therefore, via management

  I’m not clear on what that means.

> other groups and I think a few of them are a member of this group too.

  I just joined this list.  My experience has been that the *operational* side of operators are too busy keeping systems running to have much IETF involvement.

> course an example).

  That works if the policies can be described in an inter-operable way.  Doing that is hard.

> In one hand that we talk about this trust, in other

  Maybe.  If you want to to inter-domain authentication using EAP… your #1 choice is RADIUS.

> easily handled. Like the example scenario I have explained.

  I’m not clear how those situations can’t be easily handled with RADIUS.  People are largely doing similar things today.

> exchanged? How many administrative work it was needed that this happened?

  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.

  It’s a solved problem in the 3G world.

> other groups covered this scenario.

  Abfab is about roaming inside of a consortium.  It’s a light version of the 3G specs.

> it is like trusted anchor?

  It’s a trusted anchor for eduroam.  the certificate indicates that the system is a trusted member of a consortium.

> provide this trust because of privacy and perhaps security reasons.

  Eduroam uses a CA.  A CA is not *required* in order to build a consortium of trusted partners.  It’s just the easiest way to do it.

  One reason to use a CA is to control membership.  The consortium *cannot* rely on a public CA such as is done by web browsers.  The reason is that the problem is different.

  Web browsers want to know that “ietf.org” is really the IETF.  They do this by verifying that the certificate on https://ietf.org is signed by a CA which the web browser trusts.

  Consortium members want to know that other entities are members of the same consortium.  A CA specific to the consortium does this.  A top-level CA such as with a web browser doesn’t do that.

> devices to unknown networks that it never supposed to move to that network?

  Can the sensor be moved to another network?  No.  Because the networks aren’t configured to allow the sensors to roam.  The sensors aren’t configured with the knowledge of multiple networks.

> How much efforts is needed to make this happened?

  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.

> scenario but the agreements are in higher level?

  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?

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 3 Dec 2014 16:34:57 -0500

> Having said that, regarding the problem statement, if we want the user to access ISP1 and ISP2 , then there must be at some point some source of common trust (e.g. some IdP or entity that ISP1 and…

  Yes.  There are multiple companies who act as integrators for these ISPs.  There are multiple federations which define how to do different kinds of integration.

> In fact, what I understand from slide 5 is that, somehow, that trust is defined above southbound API with relationships that allow a user moving from Hotel A to Hotel B.

  The hotel already authenticates itself to the ISP through DSL.  What is needed is an API where the hotel can tell the ISP it’s prepared to do revenue sharing for additional users.  If those other users come from another ISP, then the industry standard way to authenticate them is RADIUS.

  Alan DeKok.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 3 Dec 2014 23:07:19 +0100

>   Yes.  There are multiple companies who act as integrators for these
ISPs.
> There are multiple federations which define how to do different kinds of
> integration.

What if the new network infrastructure changes the role of these companies?
Even the role of many hardware companies might change... and they are aware
of this fact... 
How can you find a role for them in the new infrastructure with SDN/NFV
players? 

> > In fact, what I understand from slide 5 is that, somehow, that trust is
defined
> above southbound API with relationships that allow a user moving from
Hotel
> A to Hotel B.
> 
>   The hotel already authenticates itself to the ISP through DSL.  What is
> needed is an API where the hotel can tell the ISP it's prepared to do
revenue
> sharing for additional users.  If those other users come from another ISP,
then
> the industry standard way to authenticate them is RADIUS.

What is the motivation for hotels to support cross domain authentication?
Or why they should support it? what is the advantage to Hotels?
I might be wrong but I think there is no motivation for a Hotel and it is
only administrative overheads for them. This is why they either would not
care or they are against this. This is of course different for a use case
like a university who are flexible and the use case is not commercial.

I will answer your other questions in your other emails.

Thanks again,
Best,
Hosnieh

---

From: Alan DeKok <[email-masked]>
Date: Wed, 3 Dec 2014 17:17:37 -0500

> What if the new network infrastructure changes the role of these companies?

  It likely will change the role.  But… most of them have been around for decades.  They are likely to stay, if only to service legacy equipment.

> How can you find a role for them in the new infrastructure with SDN/NFV

  I don’t know.  That isn’t really my concern.  If they want to be part of new systems, they will have to figure out how to do that themselves.

> What is the motivation for hotels to support cross domain authentication?

  I have no idea.  I was referencing your slides.

  Alan DeKok.

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 4 Dec 2014 00:44:03 +0100

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

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

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Thu, 4 Dec 2014 00:55:37 +0100

Hi Rafa,

Thanks  a lot for sharing your comments.

> I agree with Alan's points here. The usage of EAP/AAA is important because
> typical access points already provide that feature. Also AAA is used for
cross-
> domain authentication. As University we are used to the case where
students
> coming from other Universities can access our APs with his credentials in
their
> home institution. Eduroam and AAA-based federation make this possible.

I do not ignore the usefulness of such approaches, but the problem is that I
am not quite sure about this communication between controller and then
resources. In other words, it is no longer direct access to some
authentication server since hotspot is no longer the decision maker  but
there are some other components that might break this communication and
therefore, the current standards might need some changes to fit to such
scenario.

> Having said that, regarding the problem statement, if we want the user to
> access ISP1 and ISP2 , then there must be at some point some source of
> common trust (e.g. some IdP or entity that ISP1 and ISP2 both trust). For
> example, ISP1 and ISP2 may belong to a federation though they do not have
> direct SLAs.

Yes true. This is done via either using a shared apps provided by SDN
provider or the third party apps provided by third party company that
followed the standards and can run on different controllers from different
industries. In former case, there needs to be a SLA among SDN providers. In
latter case, SDN providers only need so follow the same common standards so
that the apps can use a common standard plugin to access and run on them.
This app can by default use a resource server. So there might be a third
party companies who provide this trust by producing apps and follow some
standards. 
Secuath role in former case might be exchanging this SLAs 
Secauth role in latter case might be a standard for the communication of
this special app to controller including authentication and authorization of
this app and all the communication of this app to controller. In this case,
the communication can be based on one of common approaches like Openstack
and secauth can provide plugin for openstak and controller to support this
shared resources.

defined
Hotel
> A to Hotel B.
True.

Thanks,
Best,
Hosnieh

---

From: Rene Struik <[email-masked]>
Date: Wed, 03 Dec 2014 21:44:27 -0500

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

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 4 Dec 2014 16:38:05 +0000

Hi Rene,

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

> very well shift to intermediaries who do transaction processing based
> on small payments. Of course, operators may try and assume this role of

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.   

> 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

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. 

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

> 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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 04 Dec 2014 18:51:33 +0100

Le 03/12/2014 19:44, Alan DeKok a écrit :
>> Folks, I have created some slides to explain where secauth can work
>> in this specific scenario that is hotspot entities' authentication
>> and authorization. I reviewed all previous comments.
>
>>> Other forums are working on the problem:
>>> https://www.wi-fi.org/passpoint-release-2-operator-best-practices-for-aaa-interface-deployment-v200
>>
>>>
I have checked it. This is true that they want to have similar function, 
but their main actor is end user. I am thinking about fully transparency 
for end-user and also Hotels or hotspot domain admins.
>
> I’ve spent time working at a WiFi inter-connect provider.
> Interconnections are *hard*.  They require human involvement.  The
> protocols are easy.  RADIUS, IPSec, etc.  The hard part is that
> everyone’s business methods, billing, etc. are different.  The
> interconnect providers do significant work to mangle each packet to /
> from disparate ISPs.
>
>> Is there any operators in this group to share the opinions from
>> operators' point of view? Telekom? O2? Vodafone? I only can discuss
>> this from industrial point of view.
>
>> Where secauth can work: 1- If more than one industries,
>> communication between SDN controllers.(interoperability of two
>> different SDN providers) 2- The whole process for interdomain and
>> cross domain authentication & probably authorization (if any
>> specific policy should be applied in new network) including
>> considering shared resources (for tokens and policies, etc.).
>> Current standards like RADIUS, etc. cannot provide cross domain
>> authentication.
>
> I have no idea what that means.  RADIUS is *widely* used on
> cross-domain authentication.  I can say without exaggeration that
> outside of 3G, it’s the *only* protocol used for cross-domain
> authentication.
>
> cross-domain authentication, where the domains require no previous
> coordination to communicate.  They only require a common CA, which
> shows that both domains are part of the same roaming consortium.
>
>> 3- seamless authentication and authorization (this is especially
>> true for sensors or small devices without keyboard to set the
>> authentication)
>
> These scenarios are widely deployed today.  e.g. medical devices
> which send telemetry data back to a central monitoring system.  The
> devices use EAP for authentication, and RADIUS for cross-domain
> authentication.

Ok when EAP is used, but how about public hotspots managed by web portal 
where users need to fill in forms?

It may be easy to connect my laptop to that airport lounge hotspot, but 
I doubt my future watch will connect as easy.

Alex

>
> Alan DeKok.
>
> _______________________________________________ Secauth mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/secauth
>