Handling of bad EAP packets - EAP methods

[Jan-Frederik Rieckers]

Hi,

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.
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.


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.).

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.

Cheers,
Janfred

[1]: https://mailarchive.ietf.org/arch/msg/radext/40nmkHtVkrWfEty_oAl93gQ4tY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4834 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20230603/4ab4694a/attachment.bin>