BTW, would it be possible to add the behavior described in rfc4590 so freeradius can create a nonce. I am not sure if the structure of freeradius supports this since the rlm_digest only returns OK if the user is authenticated. Is it possible to define the returned package in more detail? "B sends an Access-Request packet with the newly defined Digest-Method and Digest-URI attributes but without a Digest-Nonce attribute to the RADIUS server, C (step 2). C chooses a nonce and responds with an Access-Challenge (step 3)." (B=http server, C=radius server) (RFC4590 1.3) /Alex
-----Original Message----- From: freeradius-devel-bounces+alexander.schrab=axis.com@lists.freer adius.org [mailto:freeradius-devel-bounces+alexander.schrab=axis.com@lis ts.freeradius.org] On Behalf Of Alan DeKok Sent: den 18 september 2006 18:35 To: FreeRadius developers mailing list Subject: Re: rfc4590
"Alexander Schrab" <Alexander.Schrab@axis.com> wrote:
I think I have a working version. But I can't test it with the old version of digest (I had a test program, but it expired). How do you usually test freeradius?
src/tests. It includes a number of digest tests.
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
"Alexander Schrab" <Alexander.Schrab@axis.com> wrote:
BTW, would it be possible to add the behavior described in rfc4590 so freeradius can create a nonce. I am not sure if the structure of freeradius supports this since the rlm_digest only returns OK if the user is authenticated. Is it possible to define the returned package in more detail?
Yes, it's possible. See rlm_example. Do you have test vectors for the new code? I'd like to take a look at it today. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Do you have test vectors for the new code? I'd like to take a look at it today.
As for testing, the attached script (placed in src/test/digest-tests) may help. It will feed radclient with the digest-auth-xxx files located in src/tests. It must be run from its directory location. Cheers, Philippe
Test vectors? You mean like test cases? The thing is that I use a small test client based on a modified uRadiusLib right now as a test program. The client in freeradius still mangles the rfc4590 packages and makes draft versions of them... So regression testing can still be done. I will give you a copy of the client I am using so you can test with that too (it's quite standalone, so it shouldn't be hard to get working)... /Alex On Tue, 2006-09-19 at 18:50 +0200, Philippe Sultan wrote:
Do you have test vectors for the new code? I'd like to take a look at it today.
As for testing, the attached script (placed in src/test/digest-tests) may help. It will feed radclient with the digest-auth-xxx files located in src/tests. It must be run from its directory location.
Cheers,
Philippe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Or a better way of testing would be making sure that the freeradius client can create old-style and new-style packages... I will work on that today, shouldn't take too long. Found a few problems (my code errorly required Digest-Algorithm. Expect a new diff later... /Alex On Wed, 2006-09-20 at 07:46 +0200, Alexander Schrab wrote:
Test vectors? You mean like test cases? The thing is that I use a small test client based on a modified uRadiusLib right now as a test program.
The client in freeradius still mangles the rfc4590 packages and makes draft versions of them... So regression testing can still be done. I will give you a copy of the client I am using so you can test with that too (it's quite standalone, so it shouldn't be hard to get working)...
/Alex
Do you have test vectors for the new code? I'd like to take a look at it today.
As for testing, the attached script (placed in src/test/digest-tests) may help. It will feed radclient with the digest-auth-xxx files located in src/tests. It must be run from its directory location.
Cheers,
Philippe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Tue, 2006-09-19 at 18:50 +0200, Philippe Sultan wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
that today, shouldn't take too long. Found a few problems (my code errorly required Digest-Algorithm. Expect a new diff later...
Alex, just for info, the patch I posted under your bugnote mostly applies your modifications to the CVS HEAD. The particular point regarding Digest-Algorithm has been solved too. Cheers, Philippe
Yes, I understood that. But the patch isn't in good condition. I have reworked the code pretty much now (soon finished). It is a lot more readably (no offense Alan ;) ). But I'm not quite finished yet... One thing I have problem getting hang of is the special attribute handeling in eapclient.c. Why is it there? Should it be removed now or must I modify it similar to radclient.c? /Alex On Wed, 2006-09-20 at 09:49 +0200, Philippe Sultan wrote:
that today, shouldn't take too long. Found a few problems (my code errorly required Digest-Algorithm. Expect a new diff later...
Alex, just for info, the patch I posted under your bugnote mostly applies your modifications to the CVS HEAD. The particular point regarding Digest-Algorithm has been solved too.
Cheers,
Philippe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
One thing I have problem getting hang of is the special attribute handeling in eapclient.c. Why is it there? Should it be removed now or must I modify it similar to radclient.c?
Took it from your initial patch. It should be removed as for raclient.c. Posted in bugzilla.
Ok, now I have something that might be quite good. The only thing I am not all that satisfied with is the OBSELETE and OBSELETE_INTERNAL things. Not sure how to work around that though... Also in eapclient.c I removed the old code. Someone will have to check what is needed there... All the test cases succeded including copies with obselete attributes instead. Oh yeah, I have not implemented challange. This is because it was a bigger task than I expected. We need a nonce creation algorithm, methods for calculating body digest and a few more things. Can do that later, the code is prepared for implementing that feature... Happy testing :) /Alex On Wed, 2006-09-20 at 12:00 +0200, Alexander Schrab wrote:
Yes, I understood that. But the patch isn't in good condition.
I have reworked the code pretty much now (soon finished). It is a lot more readably (no offense Alan ;) ). But I'm not quite finished yet...
One thing I have problem getting hang of is the special attribute handeling in eapclient.c. Why is it there? Should it be removed now or must I modify it similar to radclient.c?
/Alex
that today, shouldn't take too long. Found a few problems (my code errorly required Digest-Algorithm. Expect a new diff later...
Alex, just for info, the patch I posted under your bugnote mostly applies your modifications to the CVS HEAD. The particular point regarding Digest-Algorithm has been solved too.
Cheers,
Philippe - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On Wed, 2006-09-20 at 09:49 +0200, Philippe Sultan wrote: - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Alexander Schrab <Alexander.Schrab@axis.com> wrote:
Oh yeah, I have not implemented challange. This is because it was a bigger task than I expected. We need a nonce creation algorithm, methods for calculating body digest and a few more things. Can do that later, the code is prepared for implementing that feature...
The nonce creation is simply calls to lrad_rand(). Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alexander Schrab <Alexander.Schrab@axis.com> wrote:
One thing I have problem getting hang of is the special attribute handeling in eapclient.c. Why is it there? Should it be removed now or must I modify it similar to radclient.c?
Ignore radeapclient. It should be removed entirely. We should be using eapol_test, from wpa_supplicant for EAP testing. It works, and it means we don't have to write client-side code for all of the EAP types. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (3)
-
Alan DeKok -
Alexander Schrab -
Philippe Sultan