Hi all,
a description of the steps needed to get nfsv4 working with mech-eap is
now available at http://www.project-moonshot.org/devwiki/testing/nfsv4/
Please note that it's quite fragile and still far from a production
quality. On the other hand, it's working :-)
Also, working on that I've run into two issues with eap that I'd like to
solicit your comments/opinions about:
1. I'm using a Radius server connected to the production eduroam
infrastructure and therefore I'm able to verify common eduroam users.
However, I've found out that I can't obtain identity (i.e. gss name) of
the users that are authenticated by the other radius servers. I suppose
it has something to do with outer/inner identities and am wondering if
it's to be expected. Note that the Anonymous bit in the flags returned
by gss_accept_sec_context isn't set - only the "displayed" name is "\0".
2. The eap library doesn't seem to be able to "negotiate" particular
authN method (or at least, it behaves differently than common
wpa-supplicant). Our radius server offers TLS as the default method and
the gss client persists on using it and doesn't try anything else, like
PEAP which is available too, and which only I managed to get actually
working for authN. When I switched the configuration of the radius
server to use PEAP as default, authentication started to work.
Daniel
|