Alan DeKok | 1 Nov 05:40 2006

Re: Re : Re : Bug on Accouting-Requests proxying

Geoffroy Arnoud <garnoud <at> yahoo.co.uk> wrote:

> I agree on this. Nevertheless (correct me if I'm wrong), when
> FreeRADIUS acts as a proxy, it can be synchronous or asynchronous,
> right?

  Yes, but I'm starting to think that's wrong.  The server should just
act synchronously.  It's a LOT easier on the server, and can't be
wrong...

> We need to set different timeout and retransmit per realm (customer
> request / patch under contruction).
> Using NAS restransmissions as you suggest supposes to be
> synchronous, but we need asynchronous behaviour (different TO /
> retries per realm - independant from the client).

  Why?  OK, the customers request it, that's nice... but why?  What
problem do they think it solves?

  I really don't think per-realm asynchronous retransmits help.  I
just don't see why they would matter to the home server.  Retransmits
matter to the NAS, but the NAS controls it's retransmissions...

> Using radrelay may prove to be interesting, but was not considered
> useful because, at design time, we thought FreeRADIUS did respect RFC
> regarding retransmissions of accounting requests. Maybe in a future
> release of the project, we can think about using radrelay, but not for the
> moment.

  So maintain local patches.
(Continue reading)

Automatic report from sources (radiusd) between 31.10.2006 - 01.11.2006 GMT

CVS log entries from 31.10.2006 (Tue) 09:00:01 - 01.11.2006 (Wed) 09:00:01 GMT
=====================================================
Summary by authors
=====================================================
Author: pnixon
	File: radiusd/raddb/sql/postgresql-voip-postpaid.conf; Revisions: 1.2
	File: radiusd/raddb/sql/postgresql-dialup.conf; Revisions: 1.2

=====================================================
Log entries
=====================================================
Description:
This was a BUG. Acct-Delay-Time can be subtracted from the time of arrival on the server to find the
approximate time of the event generating this Accounting-Request. I must NOT be subtracted from the Session-Time!
Modified files:
	File: radiusd/raddb/sql/postgresql-dialup.conf; Revision: 1.2;
	Date: 2006/10/31 14:38:42; Author: pnixon; Lines:  (+2 -3)
-------------------------------
Description:
All tables should start with "rad"
Modified files:
	File: radiusd/raddb/sql/postgresql-voip-postpaid.conf; Revision: 1.2;
	Date: 2006/10/31 15:00:10; Author: pnixon; Lines:  (+1 -1)
=====================================================
Summary of modified files
=====================================================
File: radiusd/raddb/sql/postgresql-dialup.conf
Revisions: 1.2
Authors: pnixon (+2 -3)
-------------------------------
(Continue reading)

Geoffroy Arnoud | 2 Nov 09:20 2006
Picon

RE : Re: Re : Re : Bug on Accouting-Requests proxying

>   Why?  OK, the customers request it, that's nice...
> but why?  What
> problem do they think it solves?
> 
>   I really don't think per-realm asynchronous
> retransmits help.  I
> just don't see why they would matter to the home
> server.  Retransmits
> matter to the NAS, but the NAS controls it's
> retransmissions...

I agree with you, and we explained them that allowing
bigger TO/retries on proxy to address slow Home AAA
won't have any result, because the NAS is the one that
controls end-users' traffic.
It's just that we are migrating their AAA proxy from
an existing non-free RADIUS server to FreeRADIUS, and
they want to keep the same features. 

Anyway. We will do the job for the migration with 
1.1.3 and some locally maintained patches. Next we
will see how FreeRADIUS evolves, and take it into
consideration for next releases.

Thanks

Geof.

	

(Continue reading)

Automatic report from sources (radiusd) between 04.11.2006 - 05.11.2006 GMT

CVS log entries from 04.11.2006 (Sat) 09:00:01 - 05.11.2006 (Sun) 09:00:01 GMT
=====================================================
Summary by authors
=====================================================
Author: nbk
	File: radiusd/man/man8/radsqlrelay.8; Revisions: 1.3
	File: radiusd/scripts/radsqlrelay; Revisions: 1.7

=====================================================
Combined list of identical log entries
=====================================================
Description:
	Add a new "-f" option to read the password from a file,
	instead of command line. (closes: #395)
	Thanks to Jakub Wartak <vnull <at> pcnet.com.pl>
Modified files:
	File: radiusd/man/man8/radsqlrelay.8; Revision: 1.3;
	Date: 2006/11/04 12:58:14; Author: nbk; Lines: (+4 -0)
	File: radiusd/scripts/radsqlrelay; Revision: 1.7;
	Date: 2006/11/04 12:58:14; Author: nbk; Lines: (+15 -3)
=====================================================
Log entries
=====================================================
=====================================================
Summary of modified files
=====================================================
File: radiusd/man/man8/radsqlrelay.8
Revisions: 1.3
Authors: nbk (+4 -0)
-------------------------------
(Continue reading)

Juan C. Sanchez-DelBarrio | 6 Nov 12:13 2006
Picon

Suggest the following patch for LDAP+EAP-TTLS+PAP+CRYPT

Hi all,

I propose the following patch to use EAP-TTLS+PAP+LDAP with CRYPT
PASSWORD. This feature would permit us to cipher the plain password in
LDAP using CRYPT hash and compare the CRYPT hash of user password from
LDAP with PAP authentication (crypt).

Best Regards,
-- 
Juan C. Sanchez-DelBarrio
Security Officer
Barcelona Supercomputing Center
http://www.bsc.es
Hi all,

I propose the following patch to use EAP-TTLS+PAP+LDAP with CRYPT
PASSWORD. This feature would permit us to cipher the plain password in
LDAP using CRYPT hash and compare the CRYPT hash of user password from
LDAP with PAP authentication (crypt).

Best Regards,
--

-- 
Juan C. Sanchez-DelBarrio
Security Officer
Barcelona Supercomputing Center
http://www.bsc.es
(Continue reading)

Automatic report from sources (radiusd) between 05.11.2006 - 06.11.2006 GMT

CVS log entries from 05.11.2006 (Sun) 09:00:01 - 06.11.2006 (Mon) 09:00:02 GMT
=====================================================
Summary by authors
=====================================================
Author: nbk
	File: radiusd/doc/rlm_sqlcounter; Revisions: 1.5
	File: radiusd/man/man5/rlm_counter.5; Revisions: 1.2
	File: radiusd/man/man5/rlm_attr_filter.5; Revisions: 1.3
	File: radiusd/raddb/radiusd.conf.in; Revisions: 1.235
	File: radiusd/src/modules/rlm_sqlcounter/rlm_sqlcounter.c; Revisions: 1.30
	File: radiusd/src/modules/rlm_counter/rlm_counter.c; Revisions: 1.54
	File: radiusd/src/modules/rlm_attr_filter/rlm_attr_filter.c; Revisions: 1.31

=====================================================
Combined list of identical log entries
=====================================================
Description:
	Document the new "reply-name" directive.
Modified files:
	File: radiusd/doc/rlm_sqlcounter; Revision: 1.5;
	Date: 2006/11/05 19:56:40; Author: nbk; Lines: (+3 -0)
	File: radiusd/man/man5/rlm_counter.5; Revision: 1.2;
	Date: 2006/11/05 19:56:39; Author: nbk; Lines: (+4 -0)
	File: radiusd/raddb/radiusd.conf.in; Revision: 1.235;
	Date: 2006/11/05 19:56:40; Author: nbk; Lines: (+8 -6)
=====================================================
Log entries
=====================================================
Description:
	Add "post-auth" to the list of valid sections for this module.
(Continue reading)

Juan C. Sanchez-DelBarrio | 6 Nov 10:09 2006
Picon

Another patch for X509 validation

Hi again,

I follow with the idea of the other developer. In our organization, we
need that you can filter not only using check_cert_cn if not using
organizational-unit (O) of the DN. Firstly, we propose the following
patch using external script where you can define your own filter.

Best Regards,
-- 
Juan C. Sanchez-DelBarrio
Security Officer
Barcelona Supercomputing Center
http://www.bsc.es
Hi again,

I follow with the idea of the other developer. In our organization, we
need that you can filter not only using check_cert_cn if not using
organizational-unit (O) of the DN. Firstly, we propose the following
patch using external script where you can define your own filter.

Best Regards,
--

-- 
Juan C. Sanchez-DelBarrio
Security Officer
Barcelona Supercomputing Center
http://www.bsc.es
(Continue reading)

Daniel Larsson | 6 Nov 11:48 2006

Re: Suggest the following patch for LDAP+EAP-TTLS+PAP+CRYPT

> Best Regards,
>  =20
> -----------------------------------------------------------------------=
-
>
> diff -urN ./src/modules/rlm_ldap/rlm_ldap.c ../freeradius-1.1.3-crypt-l=
dap/src/modules/rlm_ldap/rlm_ldap.c
> --- ./src/modules/rlm_ldap/rlm_ldap.c	2006-05-09 01:45:49.000000000 +02=
00
> +++ ../freeradius-1.1.3-crypt-ldap/src/modules/rlm_ldap/rlm_ldap.c	2006=
-07-18 16:24:42.734009032 +0200
>  <at>  <at>  -2511,6 +2511,15  <at>  <at> 
>  					DEBUG("rlm_ldap: Attribute %s has no value", element->attr);
>  					continue;
>  				}
> +			=09
> +				if (value[0] =3D=3D '{' && !strcmp(element->attr, "userPassword"))=
 {
> +					char *aux_value =3D strstr(value, "}");
> +					if (aux_value) {=09
> +						aux_value++;
> +						value =3D aux_value;=09
> +					}
> +					DEBUG("rlm_ldap: Delete {CRYPT} from attribute %s", element->attr=
);		=09
> +				}
> =20
>  				DEBUG("rlm_ldap: Adding LDAP attribute %s as RADIUS attribute %s %=
s %s",
>  				      element->attr, element->radius_attr,
(Continue reading)

Alan DeKok | 6 Nov 16:40 2006

Re: Suggest the following patch for LDAP+EAP-TTLS+PAP+CRYPT

"Juan C. Sanchez-DelBarrio" <carlos.sanchez <at> bsc.es> wrote:
> I propose the following patch to use EAP-TTLS+PAP+LDAP with CRYPT
> PASSWORD. This feature would permit us to cipher the plain password in
> LDAP using CRYPT hash and compare the CRYPT hash of user password from
> LDAP with PAP authentication (crypt).

  Why?  The server already supports pulling the crypt'd password from
LDAP, and comparing it to the users password via rlm_ldap.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog
Alan DeKok | 6 Nov 16:43 2006

Re: Another patch for X509 validation

"Juan C. Sanchez-DelBarrio" <carlos.sanchez <at> bsc.es> wrote:
> I follow with the idea of the other developer. In our organization, we
> need that you can filter not only using check_cert_cn if not using
> organizational-unit (O) of the DN. Firstly, we propose the following
> patch using external script where you can define your own filter.

  Ok...

> +ATTRIBUTE       X509-Subject                            1102    string
> +ATTRIBUTE       X509-Issuer                             1103    string
...
> +#define PW_X509_SUBJECT			1100
> +#define	PW_X509_ISSUER			1101

  That's a typo.

  It looks interesting, though.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

Gmane