Handling of bad EAP packets - EAP methods

[Alan DeKok]

On Jun 3, 2023, at 9:34 AM, Jan-Frederik Rieckers <rieckers+freeradius-devel at uni-bremen.de> wrote:
> in regard to the discussions currently taking place inside eduroam and at the radext WG [1] I have a comment regarding the handling of invalid EAP packets.
> 
> I personally have not yet seen an EAP packet that only had a bogous EAP method but a valid length and code.

  I think the odds of that happening are small:

* first octet is 1  (odds are about 2^8 against)

* second two octets are exactly the length of the EAP message (odds are 2^16 against), if the data is random

* third octet is ignored

* fourth octet is valid EAP type, say 1..128, so 2^1

  Which brings us to a chance of about one in 2^25 for random data to be a valid EAP packet.  I'd put the odds even lower, considering the actual data seems to be other protocols.

  i.e. most protocols use different encoding formats than EAP, so they will *always* be "well formed" for the other protocol, and always "malformed" for EAP.

> Since there may appear new EAP methods and there is a serious problem in getting people to update their RADIUS servers once the server is running (and the additional problem that this would be incredibly hard to spot), I would suggest, leaving the "max_eap_type" out or at least disabling it by default.
> 
> If I'm reading the source code correctly, currently it defaults to 52, which would disable at least EAP-EKE v1, PT-EAP, EAP-TEAP and EAP-NOOB.

  We can update that.  We could probably just bump it to 128, and it would be good enough for 10 years.

> I.e. in eduroam this could lead to a policy violation, since those may be valid EAP messages and the policy prohibits any party from modifying the contents of the EAP message (which, at least IMHO also means that those packets MUST NOT be rejected if they are formally valid. I think rejecting them based on invalid length is justifiable.).

  Sure.

> Same argumentation (although probably less likely) goes for the EAP code. There may be future additions to the EAP protocol that add new EAP codes, but here it may be acceptable to reject these EAP packets for now and release an update if there is any future ambition to add new code points.

  That makes sense.

  I'll push some fixes.

  Alan DeKok.