I don't care about client authorization -- there should be server-side ACLs
for this.
Right.
I guess for EAP-TLS, server authorization isn't a huge deal. If an
unauthorized server is giving you access to the network, what difference
does it make to a client? The only compromise is maybe that of user
confidentiality. What worries me are improperly authorized servers for
something like PEAP+MSCHAPv2, where a dictionary attack against a client's
password might be possible.
My biggest worry is that someone, for example, hacks a web server, steals
the key pair, fires up a rogue AP+AAA, and starts stealing client
passwords.
They wouldn't even have to steal the key pair. All they'd have to do is
start a modified RADIUS service and get a rogue AP to point to it.
The user is never presented with a dialog box saying "by the
way, you're talking to CN=www.domain.net, not CN=aaa.domain.net". Oh, and
be sure to check the CRL to see if it's been revoked or not.
Typically the client will not check for a particular FQDN in the
subjectAltName field in the server cert, only a pattern (e.g. *.domain.net).
CRL checking has to occur after the fact, unless the client already has
connectivity; most implementations don't seem to do the checks at all.
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
