> In terms of server authorization, the benefit is unclear to me. Assuming > a server is authenticated and appears authorized along other dimensions > (chains to a trust anchor, has an appropriate name), should a client > reject it because it lacks the OIDs for the particular form of access > involved? From an architectural point of view, EAP-TLS implementations > typically leave certificate selection to the TLS implementation. RFC > 4334 support could require changes to the certificate selection code.
I don't care about client authorization -- there should be server-side ACLs for this. 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. 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. I definitely understand the deployment issues. I just wish there was some way to fix this without client-side ACLs for server authorization. -- t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
