2.1.10 Certificate Compatibility Warning

[Ben Wiechman]

On Thu, Jan 6, 2011 at 4:18 AM, Alan DeKok <aland at deployingradius.com> wrote:
> Ben Wiechman wrote:
>> I've been testing EAP-TTLS/MSCHAPv2 authentication with a network
>> device. FreeRADIUS keeps complaining about EAP sessions not finishing
>> with the link to the certificate compatibility wiki link, however the
>> authentication process completes successfully. Looking at the packet
>> exchanges more carefully it appears that the supplicant is not
>> incrementing the Packet Identifier. Every EAP packet sent by the
>> device uses an packet identifier of 0.
>
>  Ahh... a *RADIUS* packet identifier of 0.  That's... rude.

Am I to understand as well that it may not be a requirement for the
Packet Identifier to be incremented or semi-unique, but it is probably
a good best practice to recommend to the hardware vendor?


>
>> Digging through the RFCs I didn't find a requirement that the Packet
>> Identifier be incremented, only the note that it is used to correlate
>> requests and responses. This is obviously probably more difficult if
>> it never changes.
>
>  It can be re-used when the client receives a reply.
>
>> Is it a requirement that the NAS increment or change this value? It
>> would definitely seem to be the preferred choice. Or is the server a
>> bit too aggressive in detecting incomplete EAP sessions in this case?
>
>  It's a bit aggressive.  The check for incomplete sessions is done when
> the RADIUS packet is deleted.  In the *normal* case, the old packet is
> cleaned up after ~3-4 seconds.  In this case, it's deleted *immediately*
> when the server receives a new request.
>
>  The solution is simple, and can go into 2.1.11.
>

Might cut down on questions from people who actually read the debug output! :)


Ben