ISE Message-Authenticator Attribute order

[tsme]

Hi @ll,

today I came across an issue with Admin-authentication on a Juniper FW (JUNOS 22.4R3-S4.5) using RADIUS..
I can see Authentication request coming in and also being answered successfully with Access-Accept.
Unfortunately the FW refuses to let me in:

sshd: PAM_RADIUS_SEND_REQ_FAIL: Sending radius request failed with error (No valid RADIUS responses received).

After searching and debugging I came across this support articles from Juniper for specified JUNOS Version:
Article ID KB86815 (account required)
Article ID KB87923 (account required)
saying:

The Message-Authenticator is not encoded as the first attribute in the response packet, immediately after the attribute header.
For now, the workaround would be on server-side.

Anybody aware of changing/manipulating AVP orders in response packets on ISE, and putting "Message-Authenticator" on first place?

[MHM Cisco World]

You use radius or tacacs for admin?

MHM

[tsme]

Hi @MHM Cisco World 

I stated in my post that I receive the error using RADIUS

Oct 7 16:43:01 fw-name-obfuscated sshd[26120]: Message-Authenticator is not encoded as the first attribute in the response packet, immediately after the attribute header.

[MHM Cisco World]

• Cisco ISE: under the Allowed Protocol configurations, enable 'Require Message-Authenticator for all RADIUS Requests' (ref from the Cisco ISE: Blast-RADIUS (CVE-2024-3596) Protocol Spoofing Mitigation - Cisco).

check above

MHM

[tsme]

Hi,

the impact of activating this "feature" would exclude NADs which do not support/send the Message-Authenticator (MA).
I've allready checked by TCP Dumps that:

• if a NAD is sending MA, ISE responses also with a MA
• NAD auth requests without MA, are answered without MA by ISE

So basically enabling this would have an impact on devices not sending the MA in RADIUS AVP, but not changing the order.

Your suggestion would not solve the order issue:

[MHM Cisco World]

Can you contact Juniper it can bug 
the ISE sure send message-authc in access-accept 

update me if you get reply from Juniper 

thanks 

MHM

[tsme]

did so,
reply from Juniper:

The recommendation for RADIUS servers is to include the Message-Authenticator attribute in all replies to Access-Request packets. The Message-Authenticator should be encoded as the first attribute in the packet, immediately after the attribute header. Note that adding a Message-Authenticator to the end of reply packets will not mitigate the attack. When the Message-Authenticator is the last attribute in a packet, the attacker can treat the Message-Authenticator as an unknown suffix, as with the shared secret. The attacker then calculates the prefix as before, and has the RADIUS server authenticate the packet which contains the prefix.

regards

[MHM Cisco World]

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine/222287-blast-radius-cve-2024-3596-protocol-sp.html

But this doc. Show that attribute is first in order.

So either there is hacker man in middle change modify some data or ISE patch need to upgrade.

Can you open TAC sure they will suggest correct ISE ver. 

Thanks alot 

MHM

[tsme]

sorry for asking that, but where exactly did you read that (MA is first in order, sent by ISE) in the Mitigation Document mentioned?
Have read it several times and must have missed it.

I'm indeed already in conversation witth TAC.

[jkhgfdsa]

Did you work it out with TAC? I have the same problem

[tsme]

I'm still in contact with TAC, Cisco is evaluating if this could be developed as a feature but currently it is not possible to alter the position of MA in the answer packets.

[jkhgfdsa]

I also have a case with them right now. With Windows NPS server it looks like this and works: 

[ndahemmy]

After enabling Message authenticator for all radius request, is there any action required for radius Client let's say client like WLC ?

[Michal Janowski]

Just to close the query. In RFC there is not strict recommendation to put Message-Authenticator as the first attribute in the response packet. The issue has been addressed in Junos 22.4R3-S5.11 which no longer checks if the MA is the first attribute in the response packet.

[jkhgfdsa]

Hi,

I am running 23.4R2-S2.1 and its not fixed on that version.