Troubleshooting EAP-TLS with External Certificates

[Matthew West]

Hi Alan,

> For 802.1X is a closed loop system. Only those clients authing against you should trust you, this they can be configured to trust you. ..knowing your CA. If you use a public CA then anyone else can get a cert signed by that CA for small change, they can then do eg evil twin etc attacks and badly configured clients will auth against them. ..thus giving them the users password (or easily cloud cracked mschap challenge/response)... many clients have basic security...eg only trust the CA. So local CA is the one way to ensure lowest common denominator is secure.

So the client would trust anyone holding a cert issued by the root CA?
 That's not good.

> Also there are requirements/flags in the root CA and server CA for RADIUS clients. ....and several clients do not work with wildcard server certs in RADIUS land (Note, you don't need a cert per RADIUS server either if its the same service)

Fun.  So at this point, I'm looking at either MS-CHAPv2 tied to an AD
server, using 3rd party server cert, or using self-signed certs for
authentication.  When using self-signed/generated certs, if I have
multiple locations with a RADIUS server at each location, can I use
the same user and ca certs across locations so users can roam?  Each
RADIUS server should have it's own server certificate, though,
correct?

I'm trying to understand feasibility here.  My directive was: wired
802.1X with existing user certs.

I've been doing network-specific work for the last decade (Firewalls,
routers, switches, load balancers, APs, etc.), so please excuse any
systems-specific knowledge I'm missing.  All my 802.1X work previously
was using AD, so I'm also new to using certs for network auth as well.

Thanks for your time, Alan.  I'm going back to the drawing board to
see what direction is best pursued.

Thank you,

Matthew



On Thu, Aug 25, 2016 at 10:36 AM, Alan Buxey <A.L.M.Buxey at lboro.ac.uk> wrote:
> For 802.1X is a closed loop system. Only those clients authing against you
> should trust you, this they can be configured to trust you. ..knowing your
> CA. If you use a public CA then anyone else can get a cert signed by that CA
> for small change, they can then do eg evil twin etc attacks and badly
> configured clients will auth against them. ..thus giving them the users
> password (or easily cloud cracked mschap challenge/response)... many clients
> have basic security...eg only trust the CA. So local CA is the one way to
> ensure lowest common denominator is secure. Couple this with other things -
> eg if you use a public CA you are a slave to THEIR server timeframes,
> policies etc. If that root becomes intermediate or the CA gets revoked by
> the OS your service is hosed. Also there are requirements/flags in the root
> CA and server CA for RADIUS clients. ....and several clients do not work
> with wildcard server certs in RADIUS land
> (Note, you don't need a cert per RADIUS server either if its the same
> service)
>
> Don't just take my word for it, its Best Common Practice to not use public
> CAs - ask one of the main RADIUS RFC authors ;)
>
>
> alan