mech_eap build with --enable-acceptor=no fails

[Alejandro Perez]

Trying to build mech_eap with the --enable-acceptor=no configuration option fails, because using that option removes libradsec header files from the source files, but init_sec_context.c still tries to use the PW_GSS_ACCEPTOR_* definitions for the channel bindings code.

In my opinion, not using libradsec when acceptor code is disabled is the right thing to do. What I think is wrong is using libradsec RADIUS attribute definitions from the initiator code.

Since the initiator code makes use of libeap RADIUS functions for creating the channel bindings (though the gssEapRadiusAddAttr() function), it makes more sense to add the GSS_ACCEPTOR_* definitions in libeap/src/radius/radius.h, and then use those definitions from init_sec_context.c instead of the libradsec ones.

Since these definitions are already standard defined in section 7.4 of RFC 7055, I think this addition should be taken upstream so this would be a temporary patch to our local clone of libeap.

You can find a proposed patch in my Github repository (allow_inititor_only branch).
https://github.com/alejandro-perez/mech_eap/compare/master...allow_initiator_only

[Luke Howard (lukeh-padl)]

LGTM.

Sent from my iPhone

> On 1 Mar 2018, at 19:43, Alejandro Perez <email address hidden> wrote:
>
> Public bug reported:
>
> Trying to build mech_eap with the --enable-acceptor=no configuration
> option fails, because using that option removes libradsec header files
> from the source files, but init_sec_context.c still tries to use the
> PW_GSS_ACCEPTOR_* definitions for the channel bindings code.
>
> In my opinion, not using libradsec when acceptor code is disabled is the
> right thing to do. What I think is wrong is using libradsec RADIUS
> attribute definitions from the initiator code.
>
> Since the initiator code makes use of libeap RADIUS functions for
> creating the channel bindings (though the gssEapRadiusAddAttr()
> function), it makes more sense to add the GSS_ACCEPTOR_* definitions in
> libeap/src/radius/radius.h, and then use those definitions from
> init_sec_context.c instead of the libradsec ones.
>
> Since these definitions are already standard defined in section 7.4 of
> RFC 7055, I think this addition should be taken upstream so this would
> be a temporary patch to our local clone of libeap.
>
> You can find a proposed patch in my Github repository (allow_inititor_only branch).
> https://github.com/alejandro-perez/mech_eap/compare/master...allow_initiator_only
>
> ** Affects: moonshot
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are a member of Moonshot
> Drivers, which is subscribed to Project Moonshot.
> Matching subscriptions: Moonshot Drivers
> https://bugs.launchpad.net/bugs/1752520
>
> Title:
> mech_eap build with --enable-acceptor=no fails
>
> Status in Project Moonshot:
> New
>
> Bug description:
> Trying to build mech_eap with the --enable-acceptor=no configuration
> option fails, because using that option removes libradsec header files
> from the source files, but init_sec_context.c still tries to use the
> PW_GSS_ACCEPTOR_* definitions for the channel bindings code.
>
> In my opinion, not using libradsec when acceptor code is disabled is
> the right thing to do. What I think is wrong is using libradsec RADIUS
> attribute definitions from the initiator code.
>
> Since the initiator code makes use of libeap RADIUS functions for
> creating the channel bindings (though the gssEapRadiusAddAttr()
> function), it makes more sense to add the GSS_ACCEPTOR_* definitions
> in libeap/src/radius/radius.h, and then use those definitions from
> init_sec_context.c instead of the libradsec ones.
>
> Since these definitions are already standard defined in section 7.4 of
> RFC 7055, I think this addition should be taken upstream so this would
> be a temporary patch to our local clone of libeap.
>
> You can find a proposed patch in my Github repository (allow_inititor_only branch).
> https://github.com/alejandro-perez/mech_eap/compare/master...allow_initiator_only
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/moonshot/+bug/1752520/+subscriptions

[Alejandro Perez (alejandro-perez-mendez)]

My patch was accepted by hostap upstream, meaning that as soon as we merge into our repository, we no longer require libradsec for the initiator part.

https://w1.fi/cgit/hostap/commit/?id=2ff9696d3bb6ed744318f8d5d135a99dcac4de2b