Hi
On 23 Jul 2007, at 11:21, Phil Mayers wrote:
On Mon, 2007-07-23 at 10:20 +0200, Artur Hecker wrote:
Hello
In the default configuration, if a User-Password is defined for a
user, the user can be authenticated by all applicable authentication
types. That is the sense and the beauty of the default
configuration :-)
However, in a practical deployment, a serious security policy is
likely to state the contrary: every user (or usergroup) should be
authenticated by exactly one authentication method.
Why?
Surely a method is either secure (in which case you'd let people
use it)
or insecure (in which case you'd let no-one use it)?
I would consider our deployment "practical" (>20k users, almost 400
APs)
and we don't care what method they use, as long as it's secure and
generates keys.
As I said, it is the matter of security policy, I cannot discuss it,
for it is not an opinion :-)
What you say does make sense to me, but on the other hand I still do
not see why it should be possible to authenticate a user by more than
one method. From what you are saying, one would conclude that only
one method should be used for all users. But very often it depends on
the security level of the user group and the trust you have in user
capabilities (-> security policy...)
I can give you real-world examples, which will certainly lead to
further discussions.
Case 1: To accelerate deployment, company A considers that PEAP-
MSCHAPv2 should be used by all users not having a certificate. It had
the advantage to work immediately (say against internal AD with NTLM
or SQL, etc). However, user certificates are being issued over the
time period - for the same user identity. The point thus is to
prevent users who have obtained the certificates from keeping on
using old style password auth.
Case 2: some "important users" still use TTLS-PAP but everybody
should use PEAP-MSCHAP-v2. You cannot deactivate TTLS-PAP even if you
consider it not good enough. You don't want others to use it though.
Case 3: different backends are available, each storing a part of
users with password in clear and in hash forms. Needless to say, some
users are stored in both... Wireless admins have no power on these.
Thus, TTLS-PAP and PEAP-MSCHAPv2 are used interchangeably, in some
times by the same user, even if you feel like TTLS-PAP is less secure.
And it goes on and on, even with EAP-MD5 in wired... Just don't take
the examples literally. What I am saying is that, very often, such
situations are linked to internal company processes, to compatibility
concerns, etc., sometimes you cannot deactivate an authentication
method for administrative reasons but you would like to restrain its
use as far as possible, etc.
What is the "right" (recommended) way to do it? Could not find
anything on that in Wiki. (Would be glad to add it, when finished).
Do you want to restrict everyone to a single EAP type, or different
people/groups to different EAP types?
an EAP type per group and/or user.
Background: I used to restrict users by explicitly setting for them
(their group) EAP-Type := something, according to the user profile.
However, as of 1.1.6, my wireless PEAP(-MSCHAPv2) user
authentication
does not work anymore as before: the inner PEAP authentication fails
with "cannot tunnel TLS in TLS", most probably since the authorize
module (sql) sets EAP-Type := PEAP. It *may* be just me though.
Yeah, don't do that. Have something like:
authorize {
preprocess
eap
files
}
in "users":
# group "foo" must use PEAP
DEFAULT My-Group == "foo", EAP-Type != PEAP, Auth-Type := Reject
# group "bar" must use TTLS
DEFAULT My-Group == "bar", EAP-Type != TTLS, Auth-Type := Reject
That's my problem - I think this cannot work with tunneled methods.
I think that with this config the user will be rejected whenever the
inner method has to check the password (the type is not PEAP ->
Reject).
I'm not sure since this explicit reject does not work with an SQL
backend. But I already tried the inverse logics "EAP-Type == PEAP"
instead. SQL starts by saying "no matching entry in the database
[...]", I guess since it does not find EAP-Type set to PEAP in the
first request. In the given situation (PEAP by default), that's fine
for the tunnel to start. It even finds the matching rows during the
requests in between. But, as I said, it fails when it comes to the
inner MSCHAPv2 check of the received response: it repeats "no
matching entry in the database" and concludes "no User-Password" -
because the type in the inner method is set to EAP-MSCHAPv2. I have
no idea how to OR these two (EAP-Type == PEAP OR EAP-MSCHAPv2), but
even that would not be satisfactory since it would allow to use brute
EAP-MSCHAPv2 without a tunnel.
If I'm not mistaken, it would be nice to have two different
attributes like EAP-Type and EAP-Inner-Type or something OR we need
different SQL queries for the inner and the outer methods
configurable... Am I wrong?
artur
My-Group might be populated using rlm_passwd, or you might use SQL-
Group
or LDAP-Group or whatever.
However, this only restricts the outer EAP type, *AND* relies on the
outer ID being the same as the inner ID i.e. you get no anonymous
outer
ID.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/
users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/
users.html