June 2023 - Freeradius-Devel - lists.freeradius.org

Fwd: Accessing the "Authenticator" value from within a perl script
by Lannar Dean 28 Jun '23

28 Jun '23

When using the perl module to process access-requests, is it possible to get the "Authenticator" value (NOT the Message-Authenticator)? There is a VSA which contains encoded data, which is using the encoding mechanism specified in RFC2865, which requires the Authenticator to decrypt. It does not decode properly when the dictionary specifies RFC2865 (encrypt=1) or RFC2868 (encrypt=2), because the encrypted data is sometimes larger than 192 bytes which is not supported in the Password attribute. For example, I need access to the following value, visible in a packet capture, from within my perl script: Authenticator value <https://i.stack.imgur.com/p6LTq.png> (not the Message-Authenticator AVP <https://i.stack.imgur.com/dB4q4.png>) The text to be decrypted is present in a VSA that is defined in a dictionary, such as ATTRIBUTE MyVendors-Special-Passphrase 44 string encrypt=1 (also tried encrypt=2) An example of the payload of the value is 21caa32fea486d9baf414610ea46510e9706a476812d02e21b956e35aa47501040b445702c6ff7e1f7f839480c1a26458f710af77aeae6e592b6e6910a6d93bbf31fe803d05799bcdec86b6b5c70c85fd92ad63449773ec1500069688280cfce0da532e0ece9e504fffef1cd381b69b981ac1b17a4a5ea672154dbea8d61823bb0644669f5f367b28fe6431d8a11d109ec4a8d19e6be46eca4c8085cd01c1b02fd0fc0bff7719432d8445b2cf39a0e66 I would like to decrypt the data manually inside a perl module, but in order to do that I need the Authenticator value to use as a vector to the decryption algorithm, which I haven't been able to access from my perl script. Since neither encrypt=1 nor encrypt=2 results in the correct data, I would like to do the decryption myself within perl. If I obtain the Authenticator value manually from a packet capture, I am able to complete the process, but I would like to automate this. Does anyone know of a way to get that value? Thank you in advance!

2 3

Query on UDP proxy socket using freeradius version 3.0.16
by saurabha badhai 20 Jun '23

20 Jun '23

I see UDP socket is bind to port 0 which means kernel will allocate the ephemeral port based on the available list. I am observing that the port is still in open state even though after request is served. It's listed in netstat -anp command after 2 days. There is no message served by that port for last 2 days. *netstat -anp* output udp 0 0 0.0.0.0:*26307 *0.0.0.0:* 19293/radiusd Below is *ss -anp* output udp UNCONN 0 0 *:26307 *:* users:(("radiusd",pid=19293,fd=26)) Can anyone help to answer when this socket bind to port 26307 get closed or always in open state ? Problem here if suppose want to connect to 100 different AAAs, then all socket will be in open state which may not correct. Thanks, Saurabha

4 13

Regarding backport fix of https://github.com/FreeRADIUS/freeradius-server/issues/3501 to 3.0.x branches.
by saurabha badhai 06 Jun '23

06 Jun '23

Hi, I'm using the version 3.0.16, facing similar issue as https://github.com/FreeRADIUS/freeradius-server/issues/3501. https://github.com/FreeRADIUS/freeradius-server/issues/3501#issuecomment-15… It's difficult to upgrade to 3.2.x where these fixes are available. May I know if fix available in 3.0.x branches to use, I need it immediately. Thanks, Saurabha

4 20

Handling of bad EAP packets - EAP methods
by Jan-Frederik Rieckers 03 Jun '23

03 Jun '23

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

2 2