Subject: [Secauth] My Summary of the December Conference Call

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 08 Jan 2015 16:23:06 +0100

Hi all,

in December we had a conference call and it clarified many aspects for
me. I wanted to post a short summary of what I understood (in an attempt
to see whether others got the same impression at the call).

Hosnieh explained a model using OpenFlow where the AAA client is
actually moved into the cloud. Consequently, there is no need to use
RADIUS or Diameter in such a model since the network access
authentication messages are just forwarded from the access point to the
cloud infrastructure using some tunneling mechanism.

Now, there is still a problem with that model since at the end of the
protocol dance the access point (who was previously running the AAA
client) now has to be informed about the authorization decision. At a
minimum it has to get the keys for enabling link layer security. From
the discussions on the call I got the impression that this transfer of
authorization information from the cloud infrastructure to the access
point has not yet been standardized in an OpenFlow alike model. (Note
that OpenFlow just served as an example and similar technologies could
be used that aim to delegate the execution to some other nodes.)

Did others understood the problem description in the same way?

If "yes", then the question is

 * Is this a worthwhile problem to solve? In some sense this could be
seen as a competitor to RADIUS and Diameter.
 * Are we just moving problems around here and not really advancing the
state of the art (which might a general question with OpenFlow alike
technologies IMHO)?
 * Is there indeed a standardization gap (or are we just uninformed
about the state of the art)?
 * Is the IETF the right venue to do this type of standardization work?

Thoughts?

Ciao
Hannes

---

From: Hosnieh Rafiee <[email-masked]>
Date: Fri, 9 Jan 2015 09:49:51 +0000

Hi Hannes,

Thanks a lot for sharing your opinion. 

I am just trying to answer your questions and clarify my concerns and what I think is missing here. 

> seen as a competitor to RADIUS and Diameter.

- IMO, this is true that RADIUS and other authentication protocols are working well for user authentication in current network but they were designed for not isolated network islands. There needs to consider redesign of such protocols to fit to new scenarios. They also doesn't support the application/device authentication. My question is that what protocol available to combine app authentication and authorization with user authentication? I refer everyone to my last slides enclosed to summary message. I categorized the current approaches and what I think is missing in the SDN solution architecture.

Let me give you an example, before considering SDN solution, each network could have RADIUS server and configure some clients to access network remotely or access a network via wireless, etc. The  servers and all components were in the same organizational domains but not in different organizational domains. This is , of course, not complete but it worked. For example, for cell phone networks, roaming was possible and hand over was done with some SLA exchange. They weren't supposed to be any shared virtual devices. The user who supposed to be supported in other network, was clearly defined in the new network. They might follow the same way to support their users or they might encounter the same problem when they suppose to run on SDN solution that might need to support several operators at the same time. 

In any case, the scenario that we are talking is not only cell phone networks and hand over in such networks but internet and internet resources. There might be some similar requirements as we need to consider for cell phone networks when using SDN solution. But there are also some new requirements. 

In other word, it is not only how user needs to be authenticated and assign the policies for this user but also there are new players and entities that need to be considered during the authentication and authorization because of shared network resources (among several apps) and shared network controller(s) (among some operators).

The nature of these resources are also different because everything supposed to be software based and we also need to consider the authentication of these software entities to their controllers as well as user authentication. In other word, different levels of authentication and authorization. But what is available for this solution? 
We, of course, have a language that is called REST and many communities considered it as a good way for carrying signaling information but since it is not standard, we have different open source implementations that each supports different structures. So , to run something on vendors' controller, one need to contact the vendor and ask "what plugin do you support that we can write our app based on that?". This is where I think the standard is missing so that the technical information are exchanged via  a standard protocol and only none technical part are exchanged via the paper works. I hope it is clear now.   
 
Some examples of new consideration are, virtual devices that added to the network in run time since SDN considered to be a scalable solution and authentication and authorization of this new vdevices, the integrity of user access control with network policy, etc. and also considering other factors such as performance, etc. 

>  * Are we just moving problems around here and not really advancing 
> the state of the art (which might a general question with OpenFlow 
> alike technologies IMHO)?

- Openflow or other southbound protocols are used for propagating the signaling information on devices but they do nothing with user authentication and authorization and they do not carry such information.

IMHO, something is missing in the integration of network policy and user policy. I think Vendors deal with network policy while operators or third party companies will deal with user policy. But there might be a need of integration of these policy which I see nothing is available.

There are some research papers to combine authentication mechanisms with openflow but I still did not see any real standard. ONF that works on southbound doesn't support such scenario.
In other word, it is only research and probably a few experimental implementation but not yet standard.

Openflow authentication is also not a solved problem. It is still a concern...

> about the state of the art)?

IMHO, yes

>  * Is the IETF the right venue to do this type of standardization work?

Maybe 1 or 2 years ago, IETF wasn't a right place for that but I think there have been a lot of changes at IETF and I can see a lot of efforts in different working groups on virtualization, NFV and also some new mailinglist on SDN (I haven't still considered SDN and NFV RG)

Any thought?

Thanks again,
Best,
Hosnieh

---

From: Alan DeKok <[email-masked]>
Date: Mon, 12 Jan 2015 10:47:46 -0500

> cloud infrastructure using some tunneling mechanism.

  This model is used today.  Access points talk to local systems which in turn forward the authentication request to a home network.

  This is called AAA proxying.  The “tunnelled mechanism” here is RADIUS or Diameter.

> be used that aim to delegate the execution to some other nodes.)

  I agree.  It would be best to re-use an existing method to solve this problem.

> seen as a competitor to RADIUS and Diameter.

  Because RADIUS and Diameter can do this today.

> state of the art (which might a general question with OpenFlow alike

  In this case, I think so.

> about the state of the art)?

  I’m not sure there’s a need for a new protocol.  But there could be a need for new standards about how to solve this problem.

> * Is the IETF the right venue to do this type of standardization work?

  It might be useful to have a standard architecture, and a standard provisioning method for the scenarios raised here.  But I would largely see this as similar to ABFAB.  That working group spent its time documenting where and why people would use it, and standardizing extensions to existing protocols.

  Alan DeKok.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 13 Jan 2015 10:38:48 +0100

Hello,

> Did others understood the problem description in the same way?

Architecting the placement of AAA elements may be realized by SDN/NFV 
tools, such as to obtain a more efficient authentication step for WiFi.

But I would suggest to clarify another dimension of the problem: that of 
the usecase scenario where this is needed.  Do we consider WiFi 
hotspots?  And web portal authentication?  Or do we consider cellular 
systems and EAP authentication?

> seen as a competitor to RADIUS and Diameter.

I consider the portal automation in WiFi hotspots to be a problem 
hampering smooth connectivity.  Does it need a RADIUS or EAP kind of 
solution?  Or an enhancement of some other protocol (http?  dns?) to 
realize this automation?

> state of the art (which might a general question with OpenFlow alike

We would need to identify where is a practical problem, and where is 
problem of intelect only.  Just exercising protocol design is obviously 
not enough to pursue; this should be an engineering activity aiming at 
deploying product useful to an end user.

> about the state of the art)?

Yes, there are a few protocols like dns and http which allow the web 
portals authenticators to be mean to the end user, to restrain 
connectivity, to reduce number of customers.

>   * Is the IETF the right venue to do this type of standardization work?

This is a good question.  If the protocols we look at are IETF 
protocols, and if the problem is understood as real by several IETFers, 
then this is the venue.  If the protocols are not IETF, or if the 
problem is not understood as real by several IETFers then this is not 
the venue.

Alex

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 13 Jan 2015 12:36:18 +0100

Regarding web portals and their impact on security and usability: I
agree that those are indeed problems. There may even be simple solutions
to those problems but the real challenge is with the existing
infrastructure. How do you provide incentives for the small and medium
enterprises (like all the small hotels and restaurants) to change their
infrastructure to make this happen?

Ciao
Hannes

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 13 Jan 2015 17:25:42 +0100

> infrastructure to make this happen?

This is a good question.

How does google provide incentive for me to use it and not altavista?

Alex