From: "Alan DeKok" <aland@ox.org>
"Paolo Rotela" <paolo.rotela@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?