configuring proxy base on eap-type

[Fred MAISON]

Le lundi 24 mai 2010 à 11:49 +0200, Alan DeKok a écrit :
> Fred MAISON wrote:
> > Is there any way to proxy freeradius unsupported eap-type to an external
> > radius ?
> 
>   EAP does not allow this.
> 
>   By the time EAP has decided on an EAP type, the EAP conversation is
> well underway.  Changing it mid-stream to another server won't work.
> 
> > I have a working setup using inner-tunnel.
> > If I understand correctly, in this case, inner-eap are tunneled to
> > localhost on port 1814 by default.
> 
>   Sort of.  It's not really proxied, but the basic idea is the same.
> 
> > My goal is to have eap-juac (Juniper/Funk Software) tunneled to a
> > Juniper UAC device.
> 
>   Does that appear inside of a TLS tunnel?  If so, the *inner* session
> can be proxied.
Yes, JUAC is an inner EAP protocol, inside ttls or peap. In our setup,
It must be prefered because I have powerfull client-side host-checking
features allowing to deeply control a lot of things mainly on Microsoft
and Apple workstations (update level, antivirus, and so on ...)
Customer tried to make it work with the help of Juniper's engineers
using SteelBelted in front doing proxy to UAC for inner JUAC, but they
failed because there is some other EAP protocols present in the
production network they have not been able to support after many weeks
of efforts. 
I have proposed to replace SteelBelted by freeradius, and I succeed to
pass initial testings, but my current setup was without inner-tunnel
modules correctly configured, which makes there is a lot of unneeded
ldap access (anonymous identities which does not exist in ldap backend
and so on ...) and impossibility to configure seperately outer and inner
(when present) author/authent ...

> 
>   Otherwise... no, it can't be proxied.
> 
> > I try to avoid my actual proxy setup where a specific real is tunneled
> > to UAC. The problem is that end-users can bypass UAC proxying by simply
> > changing their domain identity ...
> 
>   Then how will they be authenticated locally?  *Why* would you
> authenticate them locally?
Until I am not to sure I correctly manage all existing protocols present
in the network, I can't harden by simply rejecting this case ; I must be
sure  ... Any way, in case of outer+inner, it seems identities are not
consistently configured, so using reals is very weak.

I think I did not gave you enough information : 
* All NAS point to freeradius
* All EAP protos without inner tunnel must be authenticated by
freeradius using a ldap backend (I found existing devices on able to do
EAP-LEAP for example, but may be there is some other insecure eap types)
* juac is an innner protocol, it can be EAP-TTLS/EAP-JUAC or
EAP-PEAP/EAP-JUAC (outer/inner)
* for all other tunneled EAP-TTLS/* or EAP-EAP/*, I have to validate
inner identity against ldap for authorize (ldap radiusgroupname
membership) and authenticate (most common seems to be mschapv2 using
ntpassword recovered in ldap during authorize). outer identity will not
be checked because of encoutered client-side configuration
inconsistencies.

Best regards
Fred MAISON
> 
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html