Subject: [Secauth] Reminder: Telco today at 3 PM Berlin time

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 3 Nov 2014 07:54:03 +0000

All,

According to doodle poll, today at 3 PM Berlin time. Please check it here.
<http://doodle.com/6gsfdi5u8gptxmhz >

I will send conference call invitations to the list of attendees.

Thanks,
Best,
Hosnieh

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 4 Nov 2014 10:02:12 +0000

All,

Here is the suggestions provided by attendees during the Telco yesterday.
- Writing a short gap analysis for secauth (doesn't need to be a complete gap analysis but only to identify the scope)
- Modify the charter to address the following use case

User 1 enters gives its information to hotspot A so that it can use internet (or some services). User 1 moves to location B where hotspot B exists. He disconnected from the service and again needs to give its information to hotspot B so that it can continue using Internet (or other services). User 1 needs a mechanisms that his information automatically submitted to the new hotspot as soon as this user moves to new location and his computer registers it. This is like hand over in mobile networks but now we are talking about WAN or different public networks (possibly from different ISPs).
There is a need for a mechanism to submit the user's information from hotspot A to hotspot B so that hotspot B can authenticate this user and let this user continue using its service (internet). This process should be all automatic except the first time user gives its information to the first hotspot. (hotspot should be considered as logical devices in virtualized environment)

- Submit the above result to both IETF discussion lists and also secauth list so that folks who are not aware of this group also join to discuss.

Any thoughts?

Please also share your opinion about the date for bar meeting at IETF. I am going to schedule this on doodle.

Thanks,
Best,
Hosnieh

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Nov 2014 11:33:40 +0100

Le 04/11/2014 11:02, Hosnieh Rafiee a écrit :
> All,
>
> Here is the suggestions provided by attendees during the Telco
> yesterday. - Writing a short gap analysis for secauth (doesn't need
> to be a complete gap analysis but only to identify the scope) -
> Modify the charter to address the following use case
>
> User 1 enters gives its information to hotspot A so that it can use
> internet (or some services). User 1 moves to location B where hotspot
> B exists. He disconnected from the service and again needs to give
> its information to hotspot B so that it can continue using Internet
> (or other services). User 1 needs a mechanisms that his information
> automatically submitted to the new hotspot as soon as this user moves
> to new location and his computer registers it. This is like hand over
> in mobile networks but now we are talking about WAN or different
> public networks (possibly from different ISPs). There is a need for a
> mechanism to submit the user's information from hotspot A to hotspot
> B so that hotspot B can authenticate this user and let this user
> continue using its service (internet). This process should be all
> automatic except the first time user gives its information to the
> first hotspot. (hotspot should be considered as logical devices in
> virtualized environment)
>
>
> - Submit the above result to both IETF discussion lists and also
> secauth list so that folks who are not aware of this group also join
> to discuss.
>
> Any thoughts?

Hi Hosnieh,

The mobility scenario that may be relevant is that the user provides the 
credentials automatically to each hotspot.  It may not be the same 
credentials for each hotspot, but it should be automated.  It may not be 
just credentials but some simple info some times.

Think when one connects a laptop to a hotspot: some times user/password 
is required, some times the creditcard, or the skype id, other times 
just an email address, some other times just check to agree on the usage 
conditions.  There is a huge number of different ways in which the 
hotspots allow one to connect to it.

Some use link-layer auth, others use web capturing portals and 
firewalling rules.

Some allow for only 15minutes free, others 15minutes free renewable.

If all this were automated then the connection experience would be more 
'smooth' to the end user.  It would allow also connections of devices 
w/o screen/kbd (IoT).

I don't know whether a mechanism/protocol is needed or possible, or 
maybe just some hints from the network about that hotspot be scriptable 
or not.

AS an example, where I live there is this WiFi Connect 2.0 application 
on smartphones on which one enters complicated credentials of several 
ISPs and then the app attaches automatically to each of them when available.

It works with these particular hotspots operated by large ISPs but does 
not work with many other hotspots operated by other craftsmen.

Is there a way to turn this into an SDN feature?  (send an openflow 
message to add a firewall rule open the access).

Is it a pure software-only issue?  (no protocol involved).

Other places at IETF where this scenario may have been discussed?

Alex

>
> Please also share your opinion about the date for bar meeting at
> IETF. I am going to schedule this on doodle.
>
>
> Thanks, Best, Hosnieh
>
>
> _______________________________________________ Secauth mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/secauth
>
>

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 4 Nov 2014 07:58:29 -0500

Sent from my iPhone

> On Nov 4, 2014, at 5:33 AM, Alexandru Petrescu <[email-masked]> wrote:
> 
> The mobility scenario that may be relevant is that the user provides the credentials automatically to each hotspot.  It may not be the same credentials for each hotspot, but it should be automated.  It may not be just credentials but some simple info some times.
> 
> Think when one connects a laptop to a hotspot: some times user/password is required, some times the creditcard, or the skype id, other times just an email address, some other times just check to agree on the usage conditions.  There is a huge number of different ways in which the hotspots allow one to connect to it.
> 
> Some use link-layer auth, others use web capturing portals and firewalling rules.
> 
> If all this were automated then the connection experience would be more 'smooth' to the end user.  It would allow also connections of devices w/o screen/kbd (IoT).
> 
> I don't know whether a mechanism/protocol is needed or possible, or maybe just some hints from the network about that hotspot be scriptable or not.
> 
> AS an example, where I live there is this WiFi Connect 2.0 application on smartphones on which one enters complicated credentials of several ISPs and then the app attaches automatically to each of them when available.
> 
> It works with these particular hotspots operated by large ISPs but does not work with many other hotspots operated by other craftsmen.
> 
> Is there a way to turn this into an SDN feature?  (send an openflow message to add a firewall rule open the access).
> 

Yes, take a look at the IP Mobility WG publications.

http://www.ietf.org/wg/concluded/mobileip.html

Best regards,
Kathleen

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Nov 2014 14:38:32 +0100

> http://www.ietf.org/wg/concluded/mobileip.html

Well I think the Mobile IP related RFCs do not deal with this particular 
case.  Not sure whether you have one particular document in mind?

Alex

---

From: Hosnieh Rafiee <[email-masked]>
Date: Tue, 4 Nov 2014 13:40:34 +0000

Hi Alex,
Thanks alot for your message and the clarification of the use case.

Maybe we can divide the problem into two sub-problems
 * information requires by hotspots
 * 

> The mobility scenario that may be relevant is that the user provides
> the credentials automatically to each hotspot.  It may not be the same
> credentials for each hotspot, but it should be automated.  It may not
> be just credentials but some simple info some times.

When we want to assume that information needs to exchange among hotspots are not always the same then we might have the following scenarios: 
1- we probably need to have a resource server where keeps information about all users who want to use such service (the information that usually are taken by hotspots)

How? This can be solve via different ways (we can keep it open to solution space and let people to contribute)

What the problem is:
   - Access control for this resource server
   - Users' privacy since these information should be available somewhere on data centers and all hotspots need to access to the information they would request.
   - Security issue: resource server is hacked.
Advantage: 
   -  automation without or with minimal user involvements

For privacy issue, the possible solution would be the use of non accurate data for users and store them in this resource server or use some algorithms to remove sensitive data and then store it. Then secauth can be the framework for providing access control.

2- Something similar to the idea of Open ID is needed to be used and hotspot needs to implement such idea 
User securely provides his authentication value to the hotspot and all hotspot use the same value 
In this case no framework is needed since the application can itself re-register the same authentication value automatically to new hotspot as soon as it lost its connection. 

Problem: 
- backward compatibility
- Security issue: an attacker can claim to be a hotspot and receive this shared authentication value! If impersonating others is not a big issue (that in most cases it is)

> just an email address, some other times just check to agree on the
> usage conditions.  There is a huge number of different ways in which
> the hotspots allow one to connect to it.
> 

This is possible but needs a very secure and restricted authentication and authorization model. Because like a normal user, the attacker can also register a new rule on firewall.

> Other places at IETF where this scenario may have been discussed?

As Kathleen also mentioned, this is like mobile IPv6 however, they did not expect to have any SDN/NFV or virtualization aspects.  For example, having hotspots controlled by a SDN controller or similar scenarios. 

Mobile IPv6 has a limitation for security configuration because it depends on IPsec for security. Therefore automation for each hotspot would be an issue but probably if we think about combining it with SDN solutions then.. I guess we need a mechanisms.

Any thoughts?

Thanks again,
Best,
Hosnieh

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Nov 2014 15:03:50 +0100

Le 04/11/2014 14:40, Hosnieh Rafiee a écrit :
> Hi Alex, Thanks alot for your message and the clarification of the
> use case.
>
> Maybe we can divide the problem into two sub-problems * information
> requires by hotspots *

Maybe yes the problem may be divided into info required by the
hotspots and hotspot readiness to accept automation.  Is this what you 
meant?

>> The mobility scenario that may be relevant is that the user
>> provides the credentials automatically to each hotspot.  It may not
>> be the same credentials for each hotspot, but it should be
>> automated.  It may not be just credentials but some simple info
>> some times.
>
> When we want to assume that information needs to exchange among
> hotspots are not always the same then we might have the following
> scenarios:

Well I didnt mean the hotspots to exchange information among themselves. 
  I think the hotspots are managed by entities that differ largely in 
their interest and as such wouldn't send data to each other (e.g. 
McDonald's hotspot will not talk to nearby Starbucks hotspot).

And yes, the information a laptop sends to a hotspot in order to obtain 
Internet connectivity is often very different depending on which hotspot 
the laptop connects to.

> 1- we probably need to have a resource server where keeps information
> about all users who want to use such service (the information that
> usually are taken by hotspots)

Well yes, that is a possibility.  It has the advantage of ability to 
better control everything, perhaps by using a single 'super' identifier.

But the requirements for solutions could also include mechanisms that do 
not require a central server.

There could be requirements for: solutions involving a 'super' server, 
solutions not involving any additional server, solutions requiring 
modifications of the hotspot Controllers, solutions _not_ requiring so.

Maybe _minimal_ modifications to Controllers.

> How? This can be solve via different ways (we can keep it open to
> solution space and let people to contribute)
>
> What the problem is: - Access control for this resource server
>
> - Users' privacy since these information should be available
> somewhere on data centers and all hotspots need to access to the
> information they would request.
>

I agree.

> For privacy issue, the possible solution would be the use of non
> accurate data for users and store them in this resource server or use
> some algorithms to remove sensitive data and then store it. Then
> secauth can be the framework for providing access control.
>
> 2- Something similar to the idea of Open ID is needed to be used and
> hotspot needs to implement such idea User securely provides his
> authentication value to the hotspot and all hotspot use the same
> value In this case no framework is needed since the application can
> itself re-register the same authentication value automatically to new
> hotspot as soon as it lost its connection.
>
> Problem: - backward compatibility

I agree.

I think in addition to OpenID there are also SkypeIDs, and maybe others?

> - Security issue: an attacker can claim to be a hotspot and receive
> this shared authentication value! If impersonating others is not a
> big issue (that in most cases it is)

I agree.

>> Think when one connects a laptop to a hotspot: some times
>> user/password is required, some times the creditcard, or the skype
>> id, other times just an email address, some other times just check
>> to agree on the usage conditions.  There is a huge number of
>> different ways in which the hotspots allow one to connect to it.
>>
>> If all this were automated then the connection experience would be
>> more 'smooth' to the end user.  It would allow also connections of
>> devices w/o screen/kbd (IoT).
>>
>> I don't know whether a mechanism/protocol is needed or possible,
>> or maybe just some hints from the network about that hotspot be
>> scriptable or not.
>>
>> AS an example, where I live there is this WiFi Connect 2.0
>> application on smartphones on which one enters complicated
>> credentials of several ISPs and then the app attaches automatically
>> to each of them when available.
>>
>> It works with these particular hotspots operated by large ISPs but
>> does not work with many other hotspots operated by other
>> craftsmen.
>>
>> Is there a way to turn this into an SDN feature?  (send an
>> openflow message to add a firewall rule open the access).
>
> This is possible but needs a very secure and restricted
> authentication and authorization model. Because like a normal user,
> the attacker can also register a new rule on firewall.

I agree.

> As Kathleen also mentioned, this is like mobile IPv6 however, they
> did not expect to have any SDN/NFV or virtualization aspects.  For
> example, having hotspots controlled by a SDN controller or similar
> scenarios.
>
>
> Mobile IPv6 has a limitation for security configuration because it
> depends on IPsec for security. Therefore automation for each hotspot
> would be an issue but probably if we think about combining it with
> SDN solutions then.. I guess we need a mechanisms.
>
> Any thoughts?

I think that Mobile IPv6 normal working is hampered by the lack of 
automated connectivity to wifi hotspots.  Mobile IPv6 is designed and 
implemented to work standalone - much effort went into automated 
handover management: when in controlled WiFi environments the MIP 
implementations hand over very smoothly.

But when connecting to real-world hotspots the entire magnificence of 
Mobile IPv6 smooth handoverrs is lost because of this need of user 
intervention to the capturing web portals.

Were this automated hotspot security connection be in place then Mobile 
IP would work better.

Listening...

Alex

>
> Thanks again, Best, Hosnieh
>
>
>

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Tue, 4 Nov 2014 20:41:54 +0100

meant?

Yes, In other word, mechanism to handle these steps for hotspots. (sorry
that I missed the second sub-problem..)

> And yes, the information a laptop sends to a hotspot in order to 
> obtain Internet connectivity is often very different depending on 
> which hotspot the laptop connects to.

agree
 
> > 1- we probably need to have a resource server where keeps 
> > information about all users who want to use such service (the 
> > information that usually are taken by hotspots)
> 
> But the requirements for solutions could also include mechanisms that 
> do not require a central server.

Agree. 

> modifications of the hotspot Controllers, solutions _not_ requiring so.

Agree

> I think in addition to OpenID there are also SkypeIDs, and maybe others?

Yes true. I guess for secauth, we only need a unique credential. It can be
hash of something like HIT or any other values.

> implementations hand over very smoothly.

agree

> intervention to the capturing web portals.

True

> Were this automated hotspot security connection be in place then 
> Mobile IP would work better.
> 

agree. 

If I summarize our discussion:

-  A use case for secauth : To assist mobile node (end user) to move from
one hotspot to another one without having interruption in its service. 
- The scope of secauth: 
automatic registration of mobile node to new hotspot (protocols to send
authentication information when this mobile node changes its location)
In detail:
 * Detection of changing location (we might be able to use the same
mechanism used for MIP for this detection)
 * Secure exchange of authentication information 
 * Authentication of hotspot to controller for one of the following solution
scope: 
- Accessing centralized/one of distributed resource server/s for user
information
- Modifying hotspot controller (e.g. open a port on firewall, etc.) This
access should be very limited and monitored
- Exchange of user information without the need of resource server
- Accessing services without the need for running any rules on hotspot
controller.

Anything missed?

Thanks
Best,
Hosnieh

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Nov 2014 16:47:00 -0500

Hosnieh Rafiee <[email-masked]> wrote:
    > internet (or some services). User 1 moves to location B where hotspot B
    > exists. He disconnected from the service and again needs to give its
    > information to hotspot B so that it can continue using Internet (or
    > other services). User 1 needs a mechanisms that his information
    > in mobile networks but now we are talking about WAN or different public
    > networks (possibly from different ISPs).

    > There is a need for a mechanism to submit the user's information from
    > hotspot A to hotspot B so that hotspot B can authenticate this user and
    > let this user continue using its service (internet). This process
    > should be all automatic except the first time user gives its
    > information to the first hotspot. (hotspot should be considered as
    > logical devices in virtualized environment)

This completely sounds like moonshot and ABFAB.

This kind of mechanism that you describe occurs regularly in the eduroam
community: https://www.eduroam.org/
    eduroam allows students, researchers and staff from participating
    institutions to obtain Internet connectivity across campus and when visiting
    other participating institutions by simply opening their laptop.

http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ section 3.7.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 5 Nov 2014 09:44:46 +0000

Hi Michael,

Thanks a lot for your message and informing us about the conflict scope of secauth with other WG(s).

> http://datatracker.ietf.org/doc/draft-ietf-abfab-usecases/ section 3.7.

I checked this use case. I think the main difference of secauth with abfab is that
1- They focused on cloud based infrastructure but not about SDN/NFV related infrastructure and handling the complexity of authentication and authorization in such infrastructure. 

There might be requirement to run any rules on switches or so to support this scope. But abfab is only about application based communication and not lower layer while secauth also cares about handling authorization in Vswitches and Vrouters in SDN based infrastructure.

2- Their scope is organizational domains. In other word, their assumption is that a user wants to use services from a wifi that he/she already have any other services from the same provider. In other word, they did not cover all the scope of eduroam. 
I actually didn't aware of eduroam or moonshot projects. I think those projects are   is general and can be used by any place that installed and support it. Eduroam can be what I discussed in my last message

<http://www.ietf.org/mail-archive/web/secauth/current/msg00100.html> 

eduroam covers the following:
Information
But not: 

During my telco discussion I provided a general gap analysis however, I guess we need more explanation of current work items.   I am in the process of preparing a brief gap analysis

@Folks:  Any volunteers to help me for this gap analysis to provide it faster? 
This is the current list of groups for access control
abfab, ace, httpauth, kitten, oauth, softwire

This is the list of current WG for SDN/NFV
i2rs, nvo3, spring

RGs:
sdnrg, cfrg, nwcrg, nfvrg

Non-WG
SUPA, I2NSF

Any thoughts?

Thanks,
Best,
Hosnieh

---

From: Gabriel López <[email-masked]>
Date: Wed, 05 Nov 2014 12:30:55 +0100

Hi Hosneih,

    Just a minor, but important, point.

El 05/11/14 10:44, Hosnieh Rafiee escribió:
> 1- They focused on cloud based infrastructure 
Application services (Non-web) in general, cloud is one of the use cases

Regards, Gabi.
> but not about SDN/NFV related infrastructure and handling the complexity of authentication and authorization in such infrastructure. 
>

-- 
--------------------------------------------------------------
Gabriel López Millán
Departamento de Ingeniería de la Información y las Comunicaciones
University of Murcia
Spain
Tel: +34 868888504
Fax: +34 868884151
email: [email-masked]

---

From: Hosnieh Rafiee <[email-masked]>
Date: Wed, 5 Nov 2014 15:12:38 +0000

Hi Gabriel,

Thanks for clarification :-). 

@folks: Anything else that I missed?

Best,
Hosnieh

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Nov 2014 10:15:38 -0500

> 1- They focused on cloud based infrastructure but not about SDN/NFV
    > related infrastructure and handling the complexity of authentication
    > and authorization in such infrastructure.

Not the case, their goal is to extend credentials that people have, which are
sometimes used for web things, to things beyond web.

    > There might be requirement to run any rules on switches or so to
    > support this scope. But abfab is only about application based
    > communication and not lower layer while secauth also cares about
    > handling authorization in Vswitches and Vrouters in SDN based
    > infrastructure.

Not true at all, the original set of credentials are network access
credentials.  ABFAB is eduroam+++.

    > 2- Their scope is organizational domains. In other word, their
    > assumption is that a user wants to use services from a wifi that he/she
    > already have any other services from the same provider. In other word,
    > they did not cover all the scope of eduroam.

Not the case at all.

    > I actually didn't aware of eduroam or moonshot projects. I think those
    > projects are   is general and can be used by any place that installed
    > and support it. Eduroam can be what I discussed in my last message

this is existing deployed, running code that does exactly what you talked
about in your message.

    > access should be very limited and monitored

Huh?  How was that part of your message.
Now you are getting into i2nsf or something.... does the user get to open
ports, or does the network controller, based upon the authorization of the
user, do it for them?

    > - Exchange of user information without the need of resource server

Not even sure what this means.

    > - Accessing services without the need for running any rules on hotspot

what's a "hotspot controller"?
Please use 802.1X terms for me... since they spent the effort to make all
those terms up.

---

From: Rafa Marin Lopez <[email-masked]>
Date: Wed, 5 Nov 2014 16:29:39 +0100

Hi Michael:

> credentials.  ABFAB is eduroam+++.

[Rafa] Michael I don't think this sentence is accurate. ABFAB is not eduroam+++. The scope of ABFAB is clear

"This working group will specify a federated identity
    mechanism for use by other Internet protocols not based on HTML/HTTP,
    such as for instance IMAP, XMPP, SSH and NFS."

In general, credentials may differ from the network access ones. If there is a case where credentials are the same to those used for network access is ok but it is not mandatory. The thing is, since ABFAB uses EAP and AAA and eduroam also uses EAP and AAA for network access, then ABFAB may use the eduroam infrastructure and associated technologies for authenticating and authorizing application services as well. 

Best Regards.

> Please use 802.1X terms for me... since they spent the effort to make all

-------------------------------------------------------
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: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Nov 2014 18:34:00 +0100

>      other participating institutions by simply opening their laptop.

Well, eduroam is a great achievement.  I am not an user, but the 
firsthand users I hear is very positive.

On another hand, eduroam is just another operator of hotspots, as well 
as operating other bigger networks of course.  As such, one could 
realize smooth handovers between that operator's hotspots but not 
outside of it.

The seeked functionality would be one offering ability to roam between 
an eduroam Access Point and an e.g. orange Access Point, without having 
to fill in forms on a web page at each handover.

A keyboard-less client connecting to a webforms-mandatory hotspot 
authentication.  Something like that.

Alex

---

From: Hosnieh Rafiee <[email-masked]>
Date: Thu, 6 Nov 2014 10:19:26 +0000

Hi Michael,

I think Rafa already answered some of your concerned that you raised in this group.

> Huh?  How was that part of your message.

It was my previous message to the list. I guess I included the link here. 

> Now you are getting into i2nsf or something.... does the user get to
> open ports, or does the network controller, based upon the
> authorization of the user, do it for them?

I2nsf scope is NFV and the protocols needed for the customers to request security services from different service providers. For example you want to request a firewall to include it to your network. In other word, you accepted to be a customer of this service provider and you want to request a service from them. 

- secauth considers mobility (the scope is interdomain authentication and authorization during this mobility)  
- secauth only needs to modify a rule to fulfill customer's request but it is not interested to let the customers to request a new security function. 
- secauth focused on SDN cases and might also cover only a few communications with security services in the network just to fullfil customer's request

Yes this SDN controller is based upon authorization of the user in previous network and the SLAs in a new network.

> Please use 802.1X terms for me... since they spent the effort to make
> all those terms up.

Physical hotspot device only receives information via standard defined in 802.1x and submits them to data centers where the requests are processed. In other word, hotspot device is only like forwarder and  doesn't process any request and it only forwards all requests to the data center where everything controls by a centralized controller.

Thanks,
Best,
Hosnieh