radtest should always send Message-Authenticator
Here is a small 1-line patch for radtest. This was originally filed as a bug by the NSA (https://bugzilla.redhat.com/show_bug.cgi?id=630072). It would be nice if this could be applied to 2.1.12 before it's released. The patch is attached in git format and can be applied with either "git am" or "git apply <attachement>" if you save the attachment. I wrote up the justification for the change: ------------------------------------------------------------------ Originally Message-Authenticator was introduced to provide message integrity for EAP messages and originally the Message-Authenticator attribute was only required for EAP messages. But then RFC 5080 came along and suggested Message-Authenticator always be sent as best practice. Any Access-Request packet that performs authorization checks, including Call Check, SHOULD contain a Message-Authenticator attribute. RFC 5080 then goes on to say: ... server implementations may be configured to require the presence of a Message-Authenticator attribute in Access-Request packets. Requests not containing a Message-Authenticator attribute MAY then be silently discarded. The raddb/clients.conf has this configuration option to satisfy the above suggestion in RFC 5080: require_message_authenticator = no|yes If require_message_authenticator == yes then non-EAP auth-requests generated by radtest will fail because currently radtest only supplies the Message-Authenticator if EAP is being performed. With modern Radius servers (e.g. FreeRADIUS) there is no harm in providing the Message-Authenticator attribute for non-EAP packets, in fact it's actually recommended in RFC 5080. Therefore radtest should ALWAYS send the Message-Authenticator attribute. If it's EAP or if the server is configured with require_message_authenticator it must be present. If those conditions do not hold it's benign. However if require_message_authenticator is configured radtest will fail for non-EAP. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
Here is a small 1-line patch for radtest. This was originally filed as a bug by the NSA (https://bugzilla.redhat.com/show_bug.cgi?id=630072).
"You don't have permission to see that.."
It would be nice if this could be applied to 2.1.12 before it's released. The patch is attached in git format and can be applied with either "git am" or "git apply <attachement>" if you save the attachment.
Added && pushed. I suppose radtest should follow the RFC I wrote... Alan DeKok.
On 21/09/11 10:14, Alan DeKok wrote:
John Dennis wrote:
Here is a small 1-line patch for radtest. This was originally filed as a bug by the NSA (https://bugzilla.redhat.com/show_bug.cgi?id=630072).
"You don't have permission to see that.."
Can I just emphasise how INCREDIBLY ANNOYING it is when RedHat's Bugzilla does that. Which it does a lot...
On Wed, Sep 21, 2011 at 12:36:09PM +0100, Phil Mayers wrote:
On 21/09/11 10:14, Alan DeKok wrote:
John Dennis wrote:
Here is a small 1-line patch for radtest. This was originally filed as a bug by the NSA (https://bugzilla.redhat.com/show_bug.cgi?id=630072).
"You don't have permission to see that.."
I thought it was because the report was from the NSA :-)
If require_message_authenticator == yes then non-EAP auth-requests generated by radtest will fail because currently radtest only supplies the Message-Authenticator if EAP is being performed. With modern Radius servers (e.g. FreeRADIUS) there is no harm in providing the Message-Authenticator attribute for non-EAP packets, in fact it's actually recommended in RFC 5080.
Therefore radtest should ALWAYS send the Message-Authenticator attribute. If it's EAP or if the server is configured with require_message_authenticator it must be present. If those conditions do not hold it's benign. However if require_message_authenticator is configured radtest will fail for non-EAP.
There are some instances where sending a message authenticator is destructive and will break things. For example where old RADIUS proxy severs (which have not implemented any special behaviour for Message-Authenticator) are part of a proxy chain, including Message-Authenticator in requests or responses which pass through those servers, will cause the requests/responses to be dropped by the parties on the other side. Just an FYI in case you thought the modification was completely benign :). -Arran Arran Cudbard-Bell a.cudbardb@networkradius.com Technical consultant and solutions architect 15 Ave. du Granier, Meylan, France +33 4 69 66 54 50
Arran Cudbard-Bell wrote:
There are some instances where sending a message authenticator is destructive and will break things. For example where old RADIUS proxy severs
<sticks fingers in ears> LA LA LA LA Those people should upgrade. Message-Authenticator has been around for almost 10 years. If someone hasn't upgraded, tough.
Just an FYI in case you thought the modification was completely benign :).
People can still use "radclient". It can send anything, including badly formatted packets. :) Alan DeKok.
<sticks fingers in ears>
LA LA LA LA
Those people should upgrade. Message-Authenticator has been around for almost 10 years. If someone hasn't upgraded, tough.
But upgrading might cause disruption, they couldn't possibly upgrade, it might cost them customers!
Just an FYI in case you thought the modification was completely benign :).
People can still use "radclient". It can send anything, including badly formatted packets. :)
Hence the lack of obscenities :) Arran Cudbard-Bell a.cudbardb@freeradius.org Betelwiki, Betelwiki, Betelwiki.... http://wiki.freeradius.org/ !
participants (5)
-
Alan DeKok -
Arran Cudbard-Bell -
Brian Candler -
John Dennis -
Phil Mayers