[radext] Consequences of removing Message-Authenticator from RADIUS/1.1 messages

[Heikki Vatiainen <[e-mail]>]

Here's another RADIUS/1.1 implementation related topic that might be useful
to discuss.

Section 5.2. states the following about Message-Authenticator:
https://www.ietf.org/archive/id/draft-ietf-radext-radiusv11-01.html#name-message-authenticator

The Message-Authenticator attribute ([RFC3579] Section 3.2) MUST NOT be
sent over a RADIUS/1.1 connection. That attribute is no longer used or
needed.

And a bit further:

That is, a proxy which received a Message-Authenticator attribute from a
client would never forward that attribute as-is to another server. Instead,
the proxy would either suppress, or re-create, the Message-Authenticator
attribute in the outgoing request.


Here's a simple RADIUS proxy system.
C ---- P1 ---- P2 ---- S

C is a RADIUS client, P1 and P2 are Radius proxies and S is Radius server
that authenticates requests originated by C. For this example the RADIUS
Access-Request messages do not carry EAP and C adds Message-Authenticator
to the requests at its discretion.

What Radiator currently does by default is that it when it proxies a
request, it re-creates Message-Authenticator if it were received from a
previous hop. With RADIUS over UDP and RadSec S will receive requests with
Message-Authenticator depending on whether C added them to its requests or
not.

If the link between P1 and P2 is upgraded to RADIUS/1.1, P2 no longer sees
Message-Authenticator attribute in messages received from P1 and therefore
will not add them to the requests sent to S.

For example:
https://www.ietf.org/archive/id/draft-grayson-radext-rabble-01.html would
likely benefit from Message-Authenticator when it's Access-Requests are
transferred over RADIUS/UDP links. The current version of the draft does
not require Message-Authenticator, but lets pretend it does for the sake of
an example.

When a RABBLE request is proxied over a RADIUS/1.1 link, such as P1 -> P2
above, the Message-Authenticator is dropped. It's not likely that P2 would
know about RABBLE and what it requires and would need a hint
(Message-Authenticator in requests received from P1) to re-create it when
proxying to S.

There are likely a number of other cases too where a similar problem could
arise. It can be worked around by configuring P2 to always add
Message-Authenticator to the forwarded requests. This would then apply to
all requests, which may not be desired either.

Should we keep Message-Authenticator in RADIUS/1.1 messages? Possibly fill
it with a random or placeholder hint that that makes it clear that it does
not contain a MD5-derived value. Or maybe use a header flag to indicate
that Message-Authenticator was stripped?

--
Heikki Vatiainen
[e-mail]