How to force EAP-Identity Request sending after EAP START
javier_sandoval_ldc at yahoo.es
Fri May 1 18:37:48 CEST 2020
I know the RFC, for start there is an exception the RFC states in 2.1EAP-Start is indicated by sending an EAP-Message attribute with a
length of 2 (no data).
the server seems to recognize it as EAP-start according to the log
This use case just is required to interoperate with a VPN server that do not initiates EAP-Identity Request by itself. That may happen as it is not mandatory at RFC 5106 section 3 (EAP-Ikev2).
In that case, the VPN server needs to tell someway to the Radius to initiate an EAP dialogue with the end customer. Using stat message is suggested also in RFC 3579 section 2.1
Rather than sending an initial EAP-Request packet to the
authenticating peer, on detecting the presence of the peer, the NAS
MAY send an Access-Request packet to the RADIUS server containing an
EAP-Message attribute signifying EAP-Start....
En viernes, 1 de mayo de 2020 18:02:21 CEST, Alan DeKok <aland at deployingradius.com> escribió:
On May 1, 2020, at 11:48 AM, JAVIER SANDOVAL via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
> Thanks a lot Alan,
> sometime ago I commented some options in eap.conf to leave just eap-mschapv2, and also applied filter attr_filter.access_challenge.post-auth to remove some attributes in access-challenge. Also think I enabled eap in authorize/auth (i think under /etc/raddb/sites-enabled/inner-tunnel). I do not think I did more. EAP was working, EAP-start is a new use case I need to support.
> I have removed the access-challenge filter to check but have the same result.
> The full debug of the access-attmpt
> (0) Received Access-Request Id 5 from 10.0.87.205:64385 to 192.168.99.9:1812 length 152
> (0) User-Name = "swan"
> (0) Acct-Session-Id = "184.108.40.206-172.20.182.6:4500-1588347078"
> (0) Calling-Station-Id = "172.20.182.6:4500"
> (0) Called-Station-Id = "220.127.116.11"
> (0) NAS-Port-Id = "tunnel-1.public:40"
> (0) NAS-Identifier = "vBNG"
> (0) EAP-Message = 0x
Yeah, that's a problem. The EAP peer MUST NOT send an empty EAP-Message attribute. See RFC 3579 Section 3.1. It should instead send 2 byte EAP start message.
Or, more commonly, an EAP Identity. Which is what 99.999% of EAP peers do.
It's not clear why you need to support EAP-Start. Perhaps explaining that may help.
> Not sure if you refer to this debug.
I've pushed a fix, which will be in the next release.
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
More information about the Freeradius-Users