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

[Artur Hecker]

Replying to myself - here comes a possible resolution for this 'EAP- 
Type restriction per user/group' thread:


A possible solution is to restrict EAP-Type but by using a different  
operator (man 5 users):

"EAP-Type += <method>"
where method is one of <PEAP, EAP-TTLS> (instead of ":=" for tunneled  
methods ; for non tunneled methods I think both should be fine).


I tested it: with a MySQL backend, a user configured as EAP-Type +=  
PEAP could use PEAP-MSChapv2 but not TTLS-PAP, while a user  
configured EAP-Type += EAP-TTLS could use TTLS-PAP but not PEAP. rlm/ 
eap - freeradius correctly reported "client wants to ttls, while we  
require peap, rejecting the user" (or vice versa).


Not sure it is the intended way, so I hope the behaviour won't change  
in the next release. But it works.



Greetings and thanks
artur






On 23 Jul 2007, at 13:14, Artur Hecker wrote:

> 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