Ready for 2.2.7?

[Alan DeKok]

On Mar 31, 2015, at 2:42 PM, Jouni Malinen <jkmalinen at 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.