Having some issues with freeradius-client. :) I've build a CDR module for FreeSwitch ( www.freeswitch.org ) that uses the radiusclient library to send accounting data. Right now, it's just sending some basic data as a proof of concept ( User-Name, Call(ed|ing)-Station, etc. ). It sends okay, but the packet is rejected by FreeRADIUS ( v1.1.3 ) with an invalid shared-secret. Here's the relevant code from the client library where it calculates the Req Authenticator: if (data->code == PW_ACCOUNTING_REQUEST) { rc_log(LOG_ERR,"DEBUG-signing accounting request\n"); total_length = rc_pack_list(data->send_pairs, secret, auth) + AUTH_HDR_LEN; auth->length = htons ((unsigned short) total_length); memset((char *) auth->vector, 0, AUTH_VECTOR_LEN); secretlen = strlen (secret); memcpy ((char *) auth + total_length, secret, secretlen); /* cparker */ rc_log(LOG_ERR,"DEBUG-code,seq %d:%d, secret %s, length %d\n", auth->code, auth->id, secret, total_length); rc_md5_calc (vector, (unsigned char *) auth, total_length + secretlen); memcpy ((char *) auth->vector, (char *) vector, AUTH_VECTOR_LEN); } This outputs: DEBUG-code,seq 4:212, secret testing123, length 204 The resulting packet ( intercepted with tcpdump ) is length 204: RADIUS, length: 204 Accounting Request (4), id: 0xd0, Authenticator: 57fe69699a09491bf38cf5e24bdd847b Accounting Status Attribute (40), length: 6, Value: Stop Username Attribute (1), length: 52, Value: starnetusa.net/ 18479630116@test-td1.starnetusa.net Called Station Attribute (30), length: 12, Value: 8478797989 Calling Station Attribute (31), length: 52, Value: starnetusa.net/18479630116@test-td1.starnetusa.net Accounting Session Time Attribute (46), length: 6, Value: 540:48:23 hours NAS Port Attribute (5), length: 6, Value: 0 Accounting Delay Attribute (41), length: 6, Value: 00 secs NAS IP Address Attribute (4), length: 6, Value: dev- cr1.starnetusa.net 0x0000: 4500 00e8 0001 4000 4011 773b d87e 901a E.....@.@.w;.~.. 0x0010: d87e 81b1 8030 0715 00d4 c3ae 04d0 00cc .~... 0.......... 0x0020: 57fe 6969 9a09 491b f38c f5e2 4bdd 847b W.ii..I.....K..{ 0x0030: 2806 0000 0002 2c26 6565 3265 3864 3062 (.....,&ee2e8d0b 0x0040: 2d61 3266 392d 3465 3233 2d38 3037 382d - a2f9-4e23-8078- 0x0050: 6638 3162 3731 3361 3732 6139 0134 7374 f81b713a72a9.4st 0x0060: 6172 6e65 7475 7361 2e6e 6574 2f31 3834 arnetusa.net/184 0x0070: 3739 3633 3031 3136 4074 6573 742d 7464 79630116@test-td 0x0080: 312e 7374 6172 6e65 7475 7361 2e6e 6574 1.starnetusa.net 0x0090: 1e0c 3834 3738 3739 3739 3839 1f34 7374 .. 8478797989.4st 0x00a0: 6172 6e65 7475 7361 2e6e 6574 2f31 3834 arnetusa.net/184 0x00b0: 3739 3633 3031 3136 4074 6573 742d 7464 79630116@test-td 0x00c0: 312e 7374 6172 6e65 7475 7361 2e6e 6574 1.starnetusa.net 0x00d0: 2e06 001d b517 0506 0000 0000 2906 0000 ............)... 0x00e0: 0000 0406 d87e 901a .....~.. Any ideas on what's wrong with this? -Chris -- Chris Parker Director, Engineering US LEC Corp. Internet Telephony & ISP Operations (888)212-0099 Fax (847)963-1302 Wholesale Internet Services http://www.megapop.net VoiceEclipse, The Fresh Alternative http://www.voiceeclipse.com NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential.
Following up my own email, after further digging, it appears that this is an MD5 related issue. FreeRADIUS uses it's own MD5.c, based on public domain implementation from OpenBSD. Client uses an MD5.c that is from RSA. I seem to recall there being issues with this in the past, which is why FreeRADIUS forces it's own MD5 to be used. Is there any reason freeradius-client couldn't use the same MD5.c/h at FreeRADIUS? -Chris On Jan 25, 2007, at 11:47 AM, Chris Parker wrote:
Having some issues with freeradius-client. :)
I've build a CDR module for FreeSwitch ( www.freeswitch.org ) that uses the radiusclient library to send accounting data.
Right now, it's just sending some basic data as a proof of concept ( User-Name, Call(ed|ing)-Station, etc. ).
It sends okay, but the packet is rejected by FreeRADIUS ( v1.1.3 ) with an invalid shared-secret.
[snip] -- Chris Parker Director, Engineering US LEC Corp. Internet Telephony & ISP Operations (888)212-0099 Fax (847)963-1302 Wholesale Internet Services http://www.megapop.net VoiceEclipse, The Fresh Alternative http://www.voiceeclipse.com NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential.
Chris Parker wrote:
Following up my own email, after further digging, it appears that this is an MD5 related issue.
FreeRADIUS uses it's own MD5.c, based on public domain implementation from OpenBSD. Client uses an MD5.c that is from RSA.
I seem to recall there being issues with this in the past, which is why FreeRADIUS forces it's own MD5 to be used.
Yes. Endian issues, etc.
Is there any reason freeradius-client couldn't use the same MD5.c/h at FreeRADIUS?
That's the goal: To have more of a shared code base. For now, it could be done with a little bit of hacking. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Thu 25 Jan 2007 22:34, Chris Parker wrote:
Following up my own email, after further digging, it appears that this is an MD5 related issue.
FreeRADIUS uses it's own MD5.c, based on public domain implementation from OpenBSD. Client uses an MD5.c that is from RSA.
I seem to recall there being issues with this in the past, which is why FreeRADIUS forces it's own MD5 to be used
Is this an architecture problem? What type of system are you running on?
Is there any reason freeradius-client couldn't use the same MD5.c/h at FreeRADIUS?
No, and yes... FreeRADIUS-Client is currently BSD licensed, and we would prefer to keep it that way to allow maximum possible usage of a "good" radius client library. A quick look at the top of md5.c in freeradius-server reveals: /* * md5.c MD5 message-digest algorithm * * Version: $Id: md5.c,v 1.19 2006/11/14 21:21:49 fcusack Exp $ * * This file is licensed under the LGPL, but is largely derived * from public domain source code. */ Then a little further down: /* The below was retrieved from * http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/crypto/md5.c?rev=1.... * with the following changes: * #includes commented out. * Support context->count as uint32_t[2] instead of uint64_t * u_int* to uint* */ cvs annotate src/lib/md5.c also shows quite minor changes by Alan and a couple of others. The others are Frank who added #include <freeradius-devel/ident.h> and nbk who changed the comments. The initial import was by Paul. Guys... Do any of you have a problem with us relicensing this file under the BSD license to allow it to be used in freeradius-client? TIA -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
Guys... Do any of you have a problem with us relicensing this file under the BSD license to allow it to be used in freeradius-client?
No. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Jan 26, 2007, at 3:24 AM, Alan DeKok wrote:
Peter Nixon wrote:
Guys... Do any of you have a problem with us relicensing this file under the BSD license to allow it to be used in freeradius-client?
No.
Cool. :) The system is Slackware 10.2. Both Freeswitch and FreeRADIUS are running on the system, running on Intel Xeon. About as vanilla a system as it gets. I replaced the freeradius-client md5 with the md5 from FreeRADIUS lib, and it works. So that definitely resolved the issue. I'll wait for Frank and Paul to chime in, and then I'll commit it to freeradius-client, assuming they have no objections. Next up is writing a sample/POC program that works without reading from a config file ( other than dictionary ), so that it's a better example of how to include radius client functionality in another application. -Chris -- Chris Parker Director, Engineering US LEC Corp. Internet Telephony & ISP Operations (888)212-0099 Fax (847)963-1302 Wholesale Internet Services http://www.megapop.net VoiceEclipse, The Fresh Alternative http://www.voiceeclipse.com NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential.
On Fri, Jan 26, 2007 at 09:34:52AM -0600, Chris Parker wrote:
On Jan 26, 2007, at 3:24 AM, Alan DeKok wrote:
Peter Nixon wrote:
Guys... Do any of you have a problem with us relicensing this file under the BSD license to allow it to be used in freeradius-client?
No.
Cool. :)
The system is Slackware 10.2. Both Freeswitch and FreeRADIUS are running on the system, running on Intel Xeon. About as vanilla a system as it gets.
I replaced the freeradius-client md5 with the md5 from FreeRADIUS lib, and it works. So that definitely resolved the issue.
I'll wait for Frank and Paul to chime in, and then I'll commit it to freeradius-client, assuming they have no objections.
I assume we're talking about the md5.c? As per bug #21 [1], it came from public domain source and so I hereby reserve no rights in copyright on md[45].[ch] or changes made to them to integrate into FreeRADIUS. (It's been brought to my attention since that you can't actually choose to put things in the public domain in the US anymore, so this is as close as I can get. It's pretty much what the original source said too. ^_^) Obviously this doesn't affect FreeRADIUS's distribution of them, as the combination of them with FreeRADIUS is controlled by the LGPL. (Same for snprintf.[ch], that was LGPL before I got to it) [1] http://bugs.freeradius.org/show_bug.cgi?id=21 -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.Com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
On Fri, Jan 26, 2007 at 04:53:17PM -0800, Frank Cusack wrote:
On January 27, 2007 11:50:38 AM +1100 Paul TBBle Hampson <Paul.Hampson@Pobox.com> wrote:
(It's been brought to my attention since that you can't actually choose to put things in the public domain in the US anymore,
Oh?
So I'm told, anyway. I'm not in the US, so I haven't researched this too hard, but it seems that since copyright in the US became automatic, the only way something goes into the public domain is to have copyright expire. -- ----------------------------------------------------------- Paul "TBBle" Hampson, B.Sc, LPI, MCSE On-hiatus Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) Paul.Hampson@Pobox.Com Of course Pacman didn't influence us as kids. If it did, we'd be running around in darkened rooms, popping pills and listening to repetitive music. -- Kristian Wilson, Nintendo, Inc, 1989 License: http://creativecommons.org/licenses/by/2.1/au/ -----------------------------------------------------------
On January 27, 2007 12:11:21 PM +1100 Paul TBBle Hampson <Paul.Hampson@Pobox.com> wrote:
On Fri, Jan 26, 2007 at 04:53:17PM -0800, Frank Cusack wrote:
On January 27, 2007 11:50:38 AM +1100 Paul TBBle Hampson <Paul.Hampson@Pobox.com> wrote:
(It's been brought to my attention since that you can't actually choose to put things in the public domain in the US anymore,
Oh?
So I'm told, anyway. I'm not in the US, so I haven't researched this too hard, but it seems that since copyright in the US became automatic, the only way something goes into the public domain is to have copyright expire.
Copyright has been automatic for a long time. You just put things into the public domain by relinquishing the copyright (at time of authorship or later). There was a recent legal attempt to make copyright opt-in, which was rejected. I think there was also something to do with abandonware which was also rejected, but I might misremember that bit. Well, could be wrong on the first bit also. :-) -frank
On Thu 25 Jan 2007 22:34, Chris Parker wrote:
Following up my own email, after further digging, it appears that this is an MD5 related issue.
FreeRADIUS uses it's own MD5.c, based on public domain implementation from OpenBSD. Client uses an MD5.c that is from RSA.
I seem to recall there being issues with this in the past, which is why FreeRADIUS forces it's own MD5 to be used.
Is there any reason freeradius-client couldn't use the same MD5.c/h at FreeRADIUS?
OK. Well everyone has chimed in with an OK, so please go ahead and commit it and update the ChangeLog This may warrent a new client release as a broken md5 implimentation is not exactly usefull :-) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Jan 27, 2007, at 5:14 AM, Peter Nixon wrote:
On Thu 25 Jan 2007 22:34, Chris Parker wrote:
Following up my own email, after further digging, it appears that this is an MD5 related issue.
FreeRADIUS uses it's own MD5.c, based on public domain implementation from OpenBSD. Client uses an MD5.c that is from RSA.
I seem to recall there being issues with this in the past, which is why FreeRADIUS forces it's own MD5 to be used.
Is there any reason freeradius-client couldn't use the same MD5.c/h at FreeRADIUS?
OK. Well everyone has chimed in with an OK, so please go ahead and commit it and update the ChangeLog
Done. :)
This may warrent a new client release as a broken md5 implimentation is not exactly usefull :-)
I'd like to contribute a new sample client which doesn't rely on reading from an external file other than the dictionary first. That should be fairly near about as complete a release as we can make, and enable the client library to be much more easily adapted to other projects. After that, I'll tackle VSA support. Thanks everyone! -Chris -- Chris Parker Director, Engineering US LEC Corp. Internet Telephony & ISP Operations (888)212-0099 Fax (847)963-1302 Wholesale Internet Services http://www.megapop.net VoiceEclipse, The Fresh Alternative http://www.voiceeclipse.com NOTICE: Message is sent IN CONFIDENCE to addressees. It may contain information that is privileged, proprietary or confidential.
Chris Parker wrote:
I'd like to contribute a new sample client which doesn't rely on reading from an external file other than the dictionary first. That should be fairly near about as complete a release as we can make, and enable the client library to be much more easily adapted to other projects.
Sounds good to me.
After that, I'll tackle VSA support.
It may be useful to add support for the weird USR / Lucent / Starent VSA's, too. The code in src/lib/radius.c should be a good template. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
This may warrent a new client release as a broken md5 implimentation is not exactly usefull :-)
I'd like to contribute a new sample client which doesn't rely on reading from an external file other than the dictionary first. That should be fairly near about as complete a release as we can make, and enable the client library to be much more easily adapted to other projects.
Sounds good.
After that, I'll tackle VSA support.
Excellent. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (5)
-
Alan DeKok -
Chris Parker -
Frank Cusack -
Paul TBBle Hampson -
Peter Nixon