Enrique de la Hoz wrote:
Well, it is not adding new fields but putting some data in the data fields of those messages that allow to do that, e.g., put a certain value in the EAP Type Data field:
This is known as "writing a new EAP method". See rlm_eap/types/rlm_eap_*/ for example code that implements most common EAP methods.
We are trying to build a PoC of an architecture that implies sending back some extra authorization info to the supplicant.
Perhaps you didn't read my previous message... sending "extra information" is something that can't really be done. The protocols have specifications that describe how they work. Any "extra information" doesn't fit into those specifications.
Our first idea was included server response in the form of an AVP but we do not get the message tunneled to the client(supplicant) back (we are currently using EAP-TTLS),
TTLS can encapsulate almost anything in the inner-tunnel session. If your data didn't get sent back, it's because you didn't do the right things.
that is the reason why we thought of modifying EAP responses, to convey that certain info that we are not able to deliver to the supplicant back. I know that it is not a clean way of doing that but it is something like our last attempt.
It won't work.
BTW, Why are not AVP tunnelled back to supplicant and do not go inside TTLS session?
I have no idea. You haven't given any information about what you tried to do, or what happened. In short, modifying EAP-Messages, or the EAP protocol won't work. Adding more data inside of a TTLS tunnel is possible. But it likely requires an understanding of the specifications and the FreeRADIUS source code before making any changes. Alan DeKok.