Re: FreeRadius Proxying and Message-Authenticator
I wonder if it is correct to discard a packet based on the presence of an attribute witch use is not defined by any standard. I've read the "aboba-radext-fixes" and I see that FR is calculating Message-Authenticator in Accounting packets this way. But there is no RFC about it... RFC2869 describes how to handle incorrect or missing Message-Authenticator in Access-* packets, it doesn't say that you must discard an Accounting packet with invalid Message Authenticator, because as you say there is no standard about how to calculate it. I suggest at least a configuration option that can help to avoid this compatibility issue, giving the user the option of accepting or not "incorrect" MAs in Accounting. I'll try to find out the algorithm used by Cisco... If I happen to be successful, I'll post it. Thanks Date: Tue, 13 Sep 2005 17:57:05 -0400 From: "Alan DeKok" <aland@ox.org> Subject: Re: FreeRadius Proxying and Message-Authenticator To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Message-ID: <20050913215705.0B8CA170D2@mail.nitros9.org> "Paolo Rotela" <paolo.rotela@bluetelecom.com> wrote:
Hi. I've downloaded FR 1.0.5 whch is supposed to have a bugfix for Message-Authenticator handling in Accounting-* messages.
The issue is that the suggested method of calculatin Message-Authenticator MAY NOT be the same as what Cisco's using. Because there's no standard, Cisco may be doing almost *anything*.
I'am missing something?
If you can find out the algorithm used by Cisco, we may be able to update FreeRADIUS to handle it. Until then, there isn't much we can do. Ing. Paolo Rotela Jefe Técnico Blue Telecom
"Paolo Rotela" <paolo.rotela@bluetelecom.com> wrote:
I wonder if it is correct to discard a packet based on the presence of an attribute witch use is not defined by any standard.
No. FreeRADIUS doesn't do that. The Message-Authenticator attribute *is* defined, but not well.
I've read the "aboba-radext-fixes" and I see that FR is calculating Message-Authenticator in Accounting packets this way. But there is no RFC about it... RFC2869 describes how to handle incorrect or missing Message-Authenticator in Access-* packets, it doesn't say that you must discard an Accounting packet with invalid Message Authenticator, because as you say there is no standard about how to calculate it.
Which is why the "Isuess & Fixes" document was written.
I suggest at least a configuration option that can help to avoid this compatibility issue, giving the user the option of accepting or not "incorrect" MAs in Accounting.
That's a security bug, and will *not* go into the server.
I'll try to find out the algorithm used by Cisco... If I happen to be successful, I'll post it.
That would be appreciated, thanks. Alan DeKOk.
From: "Alan DeKok" <aland@ox.org>
"Paolo Rotela" <paolo.rotela@bluetelecom.com> wrote:
I wonder if it is correct to discard a packet based on the presence of an attribute witch use is not defined by any standard.
No. FreeRADIUS doesn't do that.
The Message-Authenticator attribute *is* defined, but not well.
Where is it defined? RFC 2869 only talks about how to handle it in Access-* packets, and particularily the handling with respect to EAP. It doesn't say that you MUST or MAY discard an Accounting-* packet with a missing or bad Message-Authenticator. If there is an RFC in wich it says that this should be the behaviour, please give me the number, because I can't find it, and in your "Isuess and Fixes" document I couldn't find a reference wich points to such a document. On the other hand, I don't believe it's correct to discard those packets because the document in wich FR's calculation of Message-Authenticator is based is in status of DRAFT, is not yet an RFC. So what you are doing like this (IMHO) is creating your own version of RADIUS, based on a DRAFT. At the state of the art, I think, nobody can tell each other what Message-Authenticator is valid or not in this case... so nobody is able to discard a packet as "invalid", until an RFC arrives. Eng. Paolo Rotela CTO Blue Telecom
"Paolo Rotela" <paolo.rotela@bluetelecom.com> wrote:
Where is it defined? RFC 2869 only talks about how to handle it in Access-* packets, and particularily the handling with respect to EAP. It doesn't say that you MUST or MAY discard an Accounting-* packet with a missing or bad Message-Authenticator.
That's exactly what I meant.
On the other hand, I don't believe it's correct to discard those packets because the document in wich FR's calculation of Message-Authenticator is based is in status of DRAFT, is not yet an RFC. So what you are doing like this (IMHO) is creating your own version of RADIUS, based on a DRAFT.
No. *Cisco* created it's own version of RADIUS by adding a Message-Authenticator to the Accounting-Response. And it *is* legal to drop packets which don't have a valid Message-Authenticator. This is known as "security".
At the state of the art, I think, nobody can tell each other what Message-Authenticator is valid or not in this case... so nobody is able to discard a packet as "invalid", until an RFC arrives.
The packet is not a valid one, because there is no valid method of calculating Message-Authenticator. Therefore, it is an invalid packet. Alan DeKok.
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?
"Paolo Rotela" <paolo.rotela@bluetelecom.com> wrote: ... I don't think this discussion is useful. You have your opinions, but you're not responsible for server development.
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.
Accounting-Response packets are signed, even without a Message-Authenticator. This is required in the RFC's. As for what's reasonable to do,m please feel free to patch your local copy of FreeRADIUS to behave however you want.
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?
Maybe you misunderstood me. There is NO VALID VALUE for Message-Authenticator in Accounting-Response packet
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?
Because I updated the code to implement the new proposed method of calculating valid Message-Authenticators. Please stop arguing about this. If you feel strongly, patch your local server. That's why you have source. The main FreeRADIUS distribution, however, WILL NOT be patched to do anything other than what I have described. Alan DeKok.
----- Original Message ----- From: "Alan DeKok" <aland@ox.org> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Thursday, September 15, 2005 2:50 PM Subject: Re: FreeRadius Proxying and Message-Authenticator
"Paolo Rotela" <paolo.rotela@bluetelecom.com> wrote: ...
I don't think this discussion is useful. You have your opinions, but you're not responsible for server development.
I toutght that discussion was the main purpose of an "open" community... because this way all people benefits with the opinions and views of other people.
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.
Accounting-Response packets are signed, even without a Message-Authenticator. This is required in the RFC's.
This discussion is NOT about "Response-Authenticator", wich is highly documented in the RFC... this is about Message-Authenticator in Accounting packets, wich is not well documented.
As for what's reasonable to do,m please feel free to patch your local copy of FreeRADIUS to behave however you want.
Yes, I know...
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?
Maybe you misunderstood me. There is NO VALID VALUE for Message-Authenticator in Accounting-Response packet
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?
Because I updated the code to implement the new proposed method of calculating valid Message-Authenticators.
So you are implementing YOUR radius to support YOUR PROPOSED method... well it seems some propietary...
Please stop arguing about this. If you feel strongly, patch your local server. That's why you have source.
Yes, but I'm trying to keep a good product like FreeRADIUS interoperating with some known and well-distributed products, wich doesn't estrictly violates RFCs... Know that FreeRADIUS will not interoperate this way with Cisco.
The main FreeRADIUS distribution, however, WILL NOT be patched to do anything other than what I have described.
OK
"Paolo Rotela" <paolo.rotela@bluetelecom.com> wrote:
So you are implementing YOUR radius to support YOUR PROPOSED method... well it seems some propietary...
And the discussion ends there. You don't understand my points, and you have conspiracy theories about my behavior. Here's a conspiracy: Go away. Alan DeKok.
Alan DeKok wrote:
"Paolo Rotela" <paolo.rotela@bluetelecom.com> wrote:
So you are implementing YOUR radius to support YOUR PROPOSED method... well it seems some propietary...
If one wants control over a project, one should start his own project. It's clear to everybody that FreeRadius is widely used because it's strong and serves a general purpose (not to mention that it's free). So if one needs something specific to one's needs, one should contribute and hope that the project coordinators will see a general benefit. Please do not reply... I just wanted to give Alan some credit, so that the FreeRadius project will continue to evolve like it has before. -- Groeten, Regards, Salutations, Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com www.salesguide.be www.telenethotspot.be
Hi people. I'm posting this in case it can be useful to anybody that wants to do the same as me. At the moment is the only way I found to make FreeRADIUS to proxy packets to a Cisco Secure ACS. I know it's a dumb patch, it is simply an "if" wich ignores the check of attribute "Message-Authenticator" for Accounting-Response packets. Anyway I wanted to test it as far as I could. By now it was working from last Thursday up to now, and without problems. I hope some day an RFC arrives to bring light to de darkness of this attribute. I only want to clarify that this is not an specific issue that I came across. It's a gereric issue between FreeRADIUS and Cisco. This is the patch file I used in the radius.c code: # cat freeradius.patch diff -Naur freeradius-1.0.5-patched/src/lib/radius.c freeradius-1.0.5/src/lib/radius.c --- freeradius-1.0.5-patched/src/lib/radius.c 2005-09-16 09:39:53.345956517 -0300 +++ freeradius-1.0.5/src/lib/radius.c 2005-08-19 16:43:46.000000000 -0300 @@ -669,7 +669,7 @@ memset ((char *) &salocal, '\0', sizeof (salocal)); salocal.sin_family = AF_INET; salocal.sin_addr.s_addr = packet->src_ipaddr; - + return sendfromto(packet->sockfd, packet->data, (int)packet->data_len, 0, (struct sockaddr *)&salocal, sizeof(struct sockaddr_in), (struct sockaddr *)&saremote, sizeof(struct sockaddr_in)); @@ -1198,23 +1198,15 @@ break; } - /* Patch by Martin Arrieta and Paolo Rotela. - * Ignores Message-Authenticator in Accounting Response packets - * Because RFCs doesn't specify how to calculate it. - * It prevents Dropping packets when proxying Accounting-Requests - * to Cisco Secure ACS and possibily other implementations. - */ - if (packet->code != PW_ACCOUNTING_RESPONSE) { - lrad_hmac_md5(packet->data, packet->data_len, - secret, strlen(secret), calc_auth_vector); - if (memcmp(calc_auth_vector, msg_auth_vector, - sizeof(calc_auth_vector)) != 0) { - char buffer[32]; - librad_log("Received packet from %s with invalid Message-Authenticator! (Shared secret is incorrect.)", - ip_ntoa(buffer, packet->src_ipaddr)); - return -1; - } /* else the message authenticator was good */ - } + lrad_hmac_md5(packet->data, packet->data_len, + secret, strlen(secret), calc_auth_vector); + if (memcmp(calc_auth_vector, msg_auth_vector, + sizeof(calc_auth_vector)) != 0) { + char buffer[32]; + librad_log("Received packet from %s with invalid Message-Authenticator! (Shared secret is incorrect.)", + ip_ntoa(buffer, packet->src_ipaddr)); + return -1; + } /* else the message authenticator was good */ /* * Reinitialize Authenticators. ----- Original Message ----- From: "Thor Spruyt" <thor.spruyt@telenet.be> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Thursday, September 15, 2005 5:58 PM Subject: Re: FreeRadius Proxying and Message-Authenticator
Alan DeKok wrote:
"Paolo Rotela" <paolo.rotela@bluetelecom.com> wrote:
So you are implementing YOUR radius to support YOUR PROPOSED method... well it seems some propietary...
If one wants control over a project, one should start his own project.
It's clear to everybody that FreeRadius is widely used because it's strong and serves a general purpose (not to mention that it's free). So if one needs something specific to one's needs, one should contribute and hope that the project coordinators will see a general benefit.
Please do not reply... I just wanted to give Alan some credit, so that the FreeRadius project will continue to evolve like it has before.
-- Groeten, Regards, Salutations,
Thor Spruyt M: +32 (0)475 67 22 65 E: thor.spruyt@telenet.be W: www.thor-spruyt.com
www.salesguide.be www.telenethotspot.be
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Paolo Rotela -
Thor Spruyt