On Sat, 2019-04-06 at 16:51 +0300, Jouni Malinen wrote:
> On Tue, Apr 02, 2019 at 12:09:14PM -0700, James Prestwood wrote:
> > I am trying to get FILS working and it appears a RADIUS server is
> > required for this? I am using EAP-PWD as the method for full EAP
> > authentication, then trying to use FILS to authenticate using the
> > cached ERP keys. I have played around with the configuration trying
> > to
> > eliminate the RADIUS server, but regardless of what I do the FILS
> > authentication will always try to use RADIUS. The full EAP auth
> > works
> > fine, and I even see hostapd caching my ERP keys:
> >
> > EAP: Stored ERP keys 3d340950a519007f@xxxxxxxxxxx
>
> You can use either the internal EAP authentication server or an
> external
> RADIUS server for FILS shared key authentication.
>
> > After this I disconnect, and reconnect using FILS. Unfortunately
> > FILS
> > tries to use RADIUS rather than the internal EAP/ERP server, and
> > since
> > the previous run never cached the ERP keys in the RADIUS server it
> > only
> > finds the full user identity, not the derived identity (above).
> > Further
> > I see in the hostapd RADIUS server implementation there is no use
> > of
> > the erp_add_key/erp_set_key functions. This makes me think the
> > hostapd
> > RADIUS server does not support ERP?
>
> Which version of hostapd are you using on the RADIUS server?
> erp_add_key() callback was added in 2014 to radius_server.c. There is
> no
> erp_set_key, so I guess that was a type for erp_get_key() which was
> also
> added in 2014..
Ah yeah, there is no erp_set_key, I meant erp_add_key. I was able to
figure out what is happening, explained in my reply to this post, but
for a short(ish) version:
ieee802_1x_learn_identity is being called to parse out the keyName-NAI
from the ERP packet, which is then set as 'identity' on the eapol state
machine. This identity is used in ieee802_1x_encapsulate_radius as the
RADIUS_ATTR_USER_NAME attribute for the radius packet.
The issue here is RADIUS expects the full user name (e.g.
user@xxxxxxxxxxx) in order to look up/create a session. But the ERP
packet contains the keyName-NAI (e.g. 99cf9651efb22254@xxxxxxxxxxx).
Hence the lookup fails. If I hack ieee802_1x_learn_identity to instead
set my expected user name, RADIUS is happy, creates a session, grabs
the ERP keys and sends back EAP-Finish (encapsulated in FILS Wrapped
data).
So with my little hack it all works as I would expect. I haven't ever
had much luck running the hostapd hwsim tests in the past, but if you
say they work as expected then maybe its worth my time to figure it
out. If the logic I am describing does not happen with the hwsim tests
then I may be doing something incorrect. But looking at the logic in
_learn_identity, I don't really see how setting the keyName-NAI as the
RADIUS user name would ever work (unless RADIUS actually looks up the
ERP key to get the proper user name, which it doesn't AFAIK).
Thanks,
James
>
> > If the hostapd RADIUS server does not support ERP is there a way to
> > get
> > FILS to use the internal EAP/ERP server? I have tried removing all
> > the
> > radius server options, but FILS still attempts to get a response
> > from
> > RADIUS regardless.
>
> I'm not sure what you are describing here, but all the ERP and FILS
> test
> cases in tests/hwsim/test_{erp,fils}.py work fine for me. Those have
> examples of various different ways of using FILS shared key
> authentication with internal or external EAP server and with and
> without
> PMKSA caching.
>
> If some combinations do not work for you, please provide
> configuration
> files from the hostapd(s) and debug logs from them as well.
>
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
