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

[Artur Hecker]

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