On Mar 31, 2015, at 2:42 PM, Jouni Malinen <jkmalinen@gmail.com> wrote:
There is no point in using the expanded header with IETF vendor 0. I think it is allowed (with the potential caveat of MS-PEAP having an exception), though. As an example, if I configure wpa_supplicant to use expanded EAP header for EAP-MSCHAPv2 within PEAP tunnel, authentication does work against hostapd as the EAP server. Actually, this seemed to work both with PEAPv0 (four bytes of the inner EAP header removed) and PEAPv1 (full inner EAP header included). Not that I would expect anyone to use such a setup with EAP-MSCHAPv2, but anyway, yes, the expanded header can be used even within a PEAP tunnel.
OK.
As far as that specific log in the "MACSEC on Cisco 3750-X and FreeRADIUS 2.2.5" thread is concerned, that does look very similar to the output I see in my test that forced expanded EAP header to be used in the tunnel. I can reproduce the same result against FreeRADIUS 3.0.7 with my modified eapol_test version:
(8) eap_peap: Session established. Decoding tunneled attributes (8) eap_peap: PEAP state phase2 (8) eap_peap: EAP type unknown (254) (8) eap_peap: Got tunneled request (8) eap_peap: EAP-Message = 0x0208004efe0000000000001a0208004231d9f55a7fcffb4ef8c1cf17df47726130000000000000000066e764105cf7c78c7e33f67d8aa85334cf6e71900dd9ee6a006a6b6d2d6d73636861707632 (8) eap_peap: Setting User-Name to jkm-mschapv2 (8) eap_peap: Sending tunneled request to inner-tunnel (8) eap_peap: EAP-Message = 0x0208004efe0000000000001a0208004231d9f55a7fcffb4ef8c1cf17df47726130000000000000000066e764105cf7c78c7e33f67d8aa85334cf6e71900dd9ee6a006a6b6d2d6d73636861707632
I suppose that should work.
So the outer handling looks fine, but the inner tunnel handler is clearly unwilling to accept expanded EAP header.
Yeah. The EAP module just refuses to decode expanded types.
I would say that it would be reasonable to make FreeRADIUS support expanded EAP header here. RFC 3748 has following to say about this: "An implementation that supports the Expanded attribute MUST treat EAP Types that are less than 256 equivalently, whether they appear as a single octet or as the 32-bit Vendor-Type within an Expanded Type where Vendor-Id is 0."
Oops.
I guess it would be fair to say that FreeRADIUS doesn't currently support the Expanded attribute, so in that sense the MUST requirement does not apply. Anyway, it would not be that difficult to add support for this if there are real EAP clients that do decide to use expanded header with vendor=0 for some strange reason.
There are vendors doing this, I think. I'll take a look at fixing FR, but it's not overly a priority.
eapol_test supports this if you want to run a test yourself. It is not configurable, though, so the following change would be needed for such a test:
OK, thanks. Alan DeKok.