eap-ttls/mschapv2 versus eap-peap/mschapv2 behaviour

[Olivier Beytrison]

Hello,

We're in the middle of migrating all of our radius server to FR3.

This is the opportunity to discuss a the difference of behaviour between
EAP-TTLS/MSCHAPv2 and EPA-PEAP/MSCHAPv2 which is bothersome.

With EAP-TTLS/MSCHAPv2 we have the following flow

1. NAS and Freeradius establish TLS tunnel while in authorize{}
2. Once tunnel is established, the ldap/sql/ntlm_auth modules are
   executed in authorize{}
3. Then the request pass to authenticate{} and eap/mschap does theire
   job
4. The request is then passed to post-auth and the final response is
   sent to the outer tunnel

With EAP-PEAP/MSCHAPv2 the flow is somewhat different

1. NAS and Freeradius establish TLS tunnel while in authorize{}
2. Once tunnel is established, the ldap/sql/ntlm_auth modules are
   executed in authorize{}
3. Then the request pass to authenticate{} and eap does another
   round of challenge/response
4. While in authenticate, mschap does the authentication
5. The request is then passed to post-auth

This mean that with EAP-PEAP/MSCHAPv2, if the ldap/sql/xxx module in
authorize{} add attributes to the reply, they will be sent during the
last challenge/response in authenticate{}, and will not be present in
post-auth or the final access-accept.

On our side, we are doing the policying in the inner-tunnel post-auth
section, based on values directly mapped from ldap attributes to our
private dictionary through the ldap module called in authz{}

With EAP-TTLS we don't need to do anything special to make this work,
but for PEAP actually we need to use the rlm_cache to cache and restore
the attributes in post-auth.

It would be really nice if eap would cache automatically all attributes
present in the reply list if it has to do another round of
challenge/response and restore them once the final access-accept (or
reject) is reached.

Now this is a behaviour I always encountered in our configs (based on
the default shipped config). Still it's possible that it is due to
what've done. For this purpose you'll find the inner-tunnel config below
[1].

Olivier

[1]

server secure-hefr-inner-tunnel{
        authorize {
                mschap
                ntdomain
                update control {
                       Proxy-To-Realm := LOCAL
                }
                if(User-Name =~ /SOFR.(.*)$/) {
                        update request {
                                Stripped-User-Name := "%{1}"
                        }
                }
                eap {
                        ok = return
                }
                ldap
                pap
        }

        authenticate {
                Auth-Type MS-CHAP {
                        mschap
                }
                Auth-Type CHAP {
                        chap
                }
                Auth-Type PAP{
                        pap
                }
                eap
        }

        post-auth {
                Post-Auth-Type REJECT {
                        -sql
                        attr_filter.access_reject
                }
                auth_log

		# that's where we need the attributes added
		# by the ldap module in authz{}
                wireless-policy
        }
}
-- 

 Olivier Beytrison
 Network & Security Engineer, HES-SO Fribourg
 Mail: olivier at heliosnet.org