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

[Alexandre Petrescu <[e-mail]>]

Hello,

Le 08/01/2015 16:23, Hannes Tschofenig a écrit :
> 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?

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?

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

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?

>   * 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)?

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.

>   * Is there indeed a standardization gap (or are we just uninformed
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/secauth
>