- Freeradius-Devel - lists.freeradius.org

EAP/TLS OCSP Extention
by Alex Bergmann 19 Nov '10

19 Nov '10

Hi everyone! Back in 2004 I've finished my diploma thesis covering OCSP integration in the EAP/TLS module of freeRADIUS. Unfortunately I never posted the patch. To get this burden off me, I've dug through the code again, did some final adjustment and just finished the patch for the v2.1.x branch. The functionality is quite simple. After a user certificate is validated correctly it is possible to check the current status as well against an OCSP responder. Here's the debug output. [tls] --> verify return:1 [tls] --> Starting OCSP Request [ocsp] --> Resonder URL = http://127.0.0.1:80/ocsp/ [ocsp] --> Certificate is valid! I've added a new subsection inside the eap/tls configuration that makes it able to set the following settings. (A detailed description can be found in the patch.) ocsp { check_ocsp = yes define_ocsp_responder = yes ocsp_url = "http://127.0.0.1/ocsp/" } I'm aware that the EAP/TLS module was extended with a verify section that states OCSP explicitly. Nevertheless I would like to see this functionality implemented directly into the rlm_eap_tls module. Please feel free to comment on the code and on this feature in general. I'm happy about any feedback! Best regards, Alex

2 1

Updates to the "stable" branch
by Alan DeKok 19 Nov '10

19 Nov '10

The "stable" branch now has brand new attribute encoding / decoding routines. The old code was awkward and confusing. It had been gradually extended over time to do VSAs, WiMAX attributes, and then the new "extended" format: http://tools.ietf.org/html/draft-dekok-radext-radius-extensions The new code is simpler and easier to understand. Each function is short: 100 lines maximum, with most being much smaller. The functions all have consistent names, take consistent arguments, and have a common layout. The new code also has better support for WiMAX attributes. The old code would sometimes not be able to decode "long" WiMAX attributes. As a bonus, there is now a test tool which encodes/decodes RADIUS attributes. It's called "radattr" (in src/main). A sample input file is in src/tests/extended.txt. More documentation and examples are in the works. The goal is to add more tests, including tests for "bad" attributes. The tests are simple enough that they can be verified by hand, but complex enough to validate the new code. All of the existing attributes && VSAs *should* be encoded the same (or better) than before. If anyone is running the "stable" branch, please try it, and let me know if there are any issues. Alan DeKok.

1 0

Which git branch?
by Brian Candler 18 Nov '10

18 Nov '10

The documentation at http://git.freeradius.org/ says that the "master" branch is for "the next major release". However if I try to build it under Ubuntu 10.10 x86_64, it aborts with an error (see below). In any case the last commit on this branch is May 29. I have some small patches to contribute. Should I be working from "stable" or "v2.1.x"? Both have commits from Nov 11. Thanks, Brian. $ ./configure && make ... libtool: link: ranlib .libs/libfreeradius-radius.a libtool: link: ( cd ".libs" && rm -f "libfreeradius-radius.la" && ln -s "../libfreeradius-radius.la" "libfreeradius-radius.la" ) make[4]: Leaving directory `/v/git/freeradius-server/src/lib' Making all in modules... /usr/bin/make -w -C modules all make[4]: Entering directory `/v/git/freeradius-server/src/modules' make[5]: Entering directory `/v/git/freeradius-server/src/modules' Making all in rlm_acctlog... /usr/bin/make -w -C rlm_acctlog all make[6]: Entering directory `/v/git/freeradius-server/src/modules/rlm_acctlog' /bin/sh /u/home/brian/git/freeradius-server/libtool --mode=compile gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I/u/home/brian/git/freeradius-server/src -c rlm_acctlog.c libtool: compile: gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I/u/home/brian/git/freeradius-server/src -c rlm_acctlog.c -fPIC -DPIC -o .libs/rlm_acctlog.o In file included from /u/home/brian/git/freeradius-server/src/freeradius-devel/radiusd.h:107, from rlm_acctlog.c:28: /u/home/brian/git/freeradius-server/src/freeradius-devel/smodule.h:144: error: expected specifier-qualifier-list before 'RADCLIENT' make[6]: *** [rlm_acctlog.lo] Error 1 make[6]: Leaving directory `/v/git/freeradius-server/src/modules/rlm_acctlog' make[5]: *** [rlm_acctlog] Error 2 ... I did a google search for this, and found a patch from last February: https://lists.freeradius.org/pipermail/freeradius-devel/2010-February/01361… which isn't in this branch. If I apply it, then it fails here instead: ... make[6]: Entering directory `/v/git/freeradius-server/src/modules/rlm_acctlog' /bin/sh /u/home/brian/git/freeradius-server/libtool --mode=compile gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I/u/home/brian/git/freeradius-server/src -c rlm_acctlog.c libtool: compile: gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -g -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -W -Wredundant-decls -Wundef -I/u/home/brian/git/freeradius-server/src -c rlm_acctlog.c -fPIC -DPIC -o .libs/rlm_acctlog.o In file included from /u/home/brian/git/freeradius-server/src/freeradius-devel/radiusd.h:153, from rlm_acctlog.c:28: /u/home/brian/git/freeradius-server/src/freeradius-devel/smodule.h:146: error: expected specifier-qualifier-list before 'fr_tcp_radius_t' make[6]: *** [rlm_acctlog.lo] Error 1 make[6]: Leaving directory `/v/git/freeradius-server/src/modules/rlm_acctlog' make[5]: *** [rlm_acctlog] Error 2 ...

2 1

username@domain
by zouzou 10 Nov '10

10 Nov '10

Hello, I have two users: test1 and test2 I would like to grant test1 access by this syntax of username ; Username: test1@domaine1 ( exp: domaine1= DRH) I would like to grant test2 access by this syntax of username; Username: test2@domaine2 ( exp: domaine1=DG) And I would not like to grant test1 access by this syntax of username Username: test1@domaine2 ( exp: domaine2= DG) Same for user test2 I wonder if FreeRADIUS is capable of handling it , if freeradius handle it , please could you tell me how??? Best Regard. -- View this message in context: http://freeradius.1045715.n5.nabble.com/username-domain-tp3258782p3258782.h… Sent from the FreeRadius - Dev mailing list archive at Nabble.com.

3 2

rlm_wimax - MN-FA key patch
by Ben Wiechman 10 Nov '10

10 Nov '10

If you are making changes to rlm_wimax any thoughts in integrating the attached patch as well? The authenticator generates the MN-FA keys, not the AAA so this is unnecessary effort. Ben

2 1

Possible patch for memory leak in rlm_wimax
by James Ballantine 10 Nov '10

10 Nov '10

Hi again, We are seeing what I think may be a memory leak inside the rlm_wimax module: Several HMAC_CTX structures are initialised with HMAC_CTX_init(), but only the last one seems to be cleaned up with HMAC_CTX_cleanup(). I've attached a patch which removes the memory leak according to my tests. However, I don't know if my change is correct - whether a single HMAC_CTX should be re-used (as I've done in this patch), or whether a new one should be created and cleaned up for each use. I would appreciate it if someone with more familiarity than me could review this change. Thanks very much, James

2 1

[radtest] Allow spaces in shared secret
by Cedric Carree 10 Nov '10

10 Nov '10

Hi. A (very) little fix to allow usage of spaces in shared secret with radtest. --- /usr/bin/radtest 2010-11-08 09:38:23.016945454 +0100 +++ /home/cedric.carree/radtest 2010-11-09 09:51:46.012445301 +0100 @@ -50,6 +50,6 @@ then echo "Framed-Protocol = PPP" fi -) | $radclient $DICTIONARY -x $3 auth $5 +) | $radclient $DICTIONARY -x $3 auth "$5" exit $?

2 1

[PATCH] Add support for xlat'd challenge in rlm_eap_gtc
by Alexander Clouter 10 Nov '10

10 Nov '10

The FIXME in rlm_eap_gtc.c has gone on so long unloved. God said, let there be xlat'ing and so there was... This patch shamelessly steals the xlat functionality in rlm_eap_tls.c and slaps it into rlm_eap_gtc.c, thus lettings you do handy things such as: ---- challenge = "%{reply:Reply-Message}" ---- Signed-off-by: Alexander Clouter <alex(a)digriz.org.uk> --- .../rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c | 13 ++++++++----- 1 files changed, 8 insertions(+), 5 deletions(-) diff --git a/src/modules/rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c b/src/modules/rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c index b8d3a25..de7d6a2 100644 --- a/src/modules/rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c +++ b/src/modules/rlm_eap/types/rlm_eap_gtc/rlm_eap_gtc.c @@ -110,14 +110,17 @@ static int gtc_attach(CONF_SECTION *cs, void **instance) */ static int gtc_initiate(void *type_data, EAP_HANDLER *handler) { + char challenge_str[1024]; int length; EAP_DS *eap_ds = handler->eap_ds; rlm_eap_gtc_t *inst = (rlm_eap_gtc_t *) type_data; - /* - * FIXME: call radius_xlat on the challenge - */ - length = strlen(inst->challenge); + if (!radius_xlat(challenge_str, sizeof(challenge_str), inst->challenge, handler->request, NULL)) { + radlog(L_ERR, "rlm_eap_gtc: xlat failed.", inst->challenge); + return 0; + } + + length = strlen(challenge_str); /* * We're sending a request... @@ -130,7 +133,7 @@ static int gtc_initiate(void *type_data, EAP_HANDLER *handler) return 0; } - memcpy(eap_ds->request->type.data, inst->challenge, length); + memcpy(eap_ds->request->type.data, challenge_str, length); eap_ds->request->type.length = length; /* -- 1.5.6.5

2 1

Authentication by domain of company
by zouzou 10 Nov '10

10 Nov '10

Hi, I am new to FreeRADIUS. I have two users: test1 test2 I would like to grant test1 access by this syntax of username ; Username: test1@domaine1 ( exp: domaine1= DRH) I would like to grant test2 access by this syntax of username; Username: test2@domaine2 ( exp: domaine1=DG) And I would not like to grant test1 access by this syntax of username Username: test1@domaine2 ( exp: domaine2= DG) Same for user test2 I wonder if FreeRADIUS is capable of handling , if freeradius handle it , please could you tell me how??? Best Regard. -- View this message in context: http://freeradius.1045715.n5.nabble.com/Authentication-by-domain-of-company… Sent from the FreeRadius - Dev mailing list archive at Nabble.com.

2 2

Stripping FreeRadius in Proxy mode of unnecessary modules and libraries
by Gyanendra Kumar 09 Nov '10

09 Nov '10

Hi All: I have an 2.1.9 Free Radius running in proxy mode for a Wireless equipment manufacturer. Proxy serves carrier networks. This Free Radius proxy is embedded and is part of wireless gateway. I have to reduce the footprint of the Free Radius. Is there a thumb rules to remove unnecessary modules or libraries. Is there any documentation on reducing the footprint. Would like to hear from someone who has attempted this. Best Regards -Gyan

2 1