Re: [Help-gnu-radius] Thanks for your advices!

[Sergey Poznyakoff]

Hi Gerald,

Many thanks for your continuous help in the list!

> My reading of just the section you posted* would still allow for RADIUS
> to distinguish between a select that failed to get a username and a
> failed attempt to contact the database.

Well, it is very tempting to agree... See, however, the explanations below.
 
> Disclaimer: I know I'm guilty here of searching through the words to try
> to find what I want it to say. I'm also guilty in this instance of the
> time-honored tradition of (some should read this as: the bad habit of)
> trying to give more responsibility to radius...but if you'll look beyond
> both of those...

No problem, I may confess the same sins :^)
 
> I think you are using the word "matching" here to refer to something
> different than I am. That's what's changing my expectation of behavior
> even though I don't use this feature. Matching a username in the
> database is not achieved if the database can't be contacted.

There is a minor terminological confusion here. The database of users
RFC is speaking about, is contained in raddb/users file. The
SQL/DBM/LDAP/etc database (if any) is a repository of additional
requirements for the users (such as passwords, additional attributes,etc.). 

In this context, "matching" means comparing attributes from the incoming
authentication request with attributes specified in the left-side (check)
pairs of a raddb/users file. The request matches an entry when all the
attribute/value pairs from the entry are present in the request. Notice
that the so-called "internal" attributes (i.e. the ones with absolute
value > 255) are not taken into account in comparison. Only when a
matching entry is found, its internal attributes are extracted and then
used to control the authentication of the user.

The "list of requirements" referred to by the RFC actually is:

I)  The request pairs must match those from the entry
II) Any conditions implied by internal attributes found in the entry must
be met (e.g. Auth-Type, whatever it is, must succeed, the number of sessions
currently open must be less than the value of Simultaneous-Use
attribute, etc.)

Consider the following example:

DEFAULT    Auth-Type = SQL,
                     Simultaneous-Use = 1,
                     NAS-IP-Address = 10.10.10.1
           ...

Both Auth-Type and Simltaneous-Use are internal attributes, they cannot
be carried by radius requests and therefore are not used in comparison.
The only attribute left is NAS-IP-Address. Thus, this entry will match
any request that contains NAS-IP-Address = 10.10.10.1 among its A/V pairs.

Now, let's suppose an incoming request has matched this entry. The
attribute Auth-Type instructs radius to attempt SQL authentication,
which fails because the database server is down. Now, RFC says:

1)   "the RADIUS server consults a database of users to find the"
     "user whose name matches the request."

     It is obviously true, since DEFAULT by definition matches any name.

2)   "The user entry in the database contains a list of requirements"
     "which must be met to allow access for the user."

     This is not true, since the condition (II) has failed.

This leads to conclusion that the request must be rejected.

Allowing radius to select alternative user entries if the first one
has failed (due to e.g. db server being down) will considerably weaken the
security of the system as a whole, since it will actually permit the
user to select the weakest authentication method from the set of allowed
ones. The setup Konst wishes to implement seems to be the worst case:
you may log in with *any* username and *any* password while the db
server is down.

It's not that I'm contrary to the idea of back-up authentication methods,
but implementing them this way does not seem to be acceptable. I will
gladly discuss any propositions/ideas.

> > It is however possible to override this implementing an authentication
> > method upon some kind of Radius extension.
> 
> My advice to Konst is to code wisely with this advice. This will be
> fired off for every authentication so don't get too code happy or use a
> bloated language.

Yes, this is actually a rule of thumb when writing external
authentication programs/procedures.

> > Otherwise, it is possible to implement this using Guile extension.
> 
> That's just mean. :-) Impressive example, but mean.

:^)) It's way faster than firing an external program.

Regards,
Sergey