Re: The "right" way to limit a user to one EAP Type

Artur Hecker <hecker@wave-storm.com> · Mon, 23 Jul 2007 13:14:00 +0200

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