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

[Alan DeKok <[e-mail]>]

On Jan 8, 2015, at 10:23 AM, Hannes Tschofenig <[e-mail]> wrote:
> 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.

  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.

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

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

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

  Because RADIUS and Diameter can do this today.

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

  In this case, I think so.

> * Is there indeed a standardization gap (or are we just uninformed
> 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.