FreeRadius Proxying and Message-Authenticator

[Paolo Rotela]

From: "Alan DeKok" <aland at ox.org>
> "Paolo Rotela" <paolo.rotela at bluetelecom.com> wrote:

>  No.  *Cisco* created it's own version of RADIUS by adding a
> Message-Authenticator to the Accounting-Response.
>

You are right.. Cisco ALSO created it's own version of RADIUS with this damn
thing.

>  And it *is* legal to drop packets which don't have a valid
> Message-Authenticator.  This is known as "security".

RFC 2869, section 5.19. Table of attributes:

" The following table provides a guide to which attributes may be found
   in which kind of packets.  Acct-Input-Gigawords, Acct-Output-
   Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in
   an Accounting-Request packet.  Connect-Info may have 0+ instances in
   an Accounting-Request packet.  The other attributes added in this
   document must not be present in an Accounting-Request."

It doesn't say a word about this being prohibited in the Accounting-Response
packet.

Same RFC, chapter 7. Security considerations:

"The attributes other than Message-Authenticator and EAP-Message in
   this document have no additional security considerations beyond those
   already identified in [1]." //// [1] being RFC 2865.

"security" appears to be a thing of criteria, with different ones by
different people...

I'm not saying that it's good to have such a hole in the RFC, but the fact
is that there isn't a standard yet, and this behaviour is having
compatibility issues. I'm in the way to suggest a solution so everyone can
talk to each other, and I'm doing it at both sides, from my humble position.

On the other hand, what's the security difference between accepting
Accounting-Response packets without a Message-Authenticator because there is
no standard, and accepting Accounting-Response packets with an
non-recognized value of Message-Authenticator because there is no standard
about how to calculate it? The most reasonable thing to do, I think, is to
simply ignore the Attribute as it were not there.

Think about this: can you say because this that Cisco's RADIUS
implementation is not "as per RFC"? I think no... because nobody says the MA
is permitted or prohibited in Accounting-Response, and nobody says how to
calculate it.
On the other side, can you say FreeRADIUS is not "as per RFC"? No because
there is no word telling if discard or not this kind of packet.
Then why the two pieces of equipment doesn't interoperate?

What you are doing with this implementation is chosing a way to do a
non-standard thing, and "labeling" the other's way as "invalid".

>  The packet is not a valid one, because there is no valid method of
> calculating Message-Authenticator.  Therefore, it is an invalid packet.

If there is no valid method of calculating MA, how can you know that it's
invalid? In your "radius.c" from 1.0.5, at line 1201 you calculate the MA of
the packet without regarding about the packet code. Why do you do this if
there is no valid method for some of these?
In the same file, at line 1203, you are using this calculated value, again
without regarding packet code, to decide if continue or exit with error
status. Again, why, if there is no valid method?