Jouni Malinen wrote:
There should not really be any requirement for User-Name (EAP-Response/Identity) to match with CN in case of EAP-TLS.. The EAP-Response/Identity is mainly for routing and it is sent in clear, so requiring it to match with CN would prevent identity privacy.
Sure, but it hasn't seemed to be a problem so far.
But check_cert_cn is indeed a bad idea in many cases.. RFC 2716bis draft is changing the identity verification to "SHOULD NOT" require identities (EAP-Identity and CN) to be identical.. Identity from EAP-Response/Identity is mainly for routing purposes and things like VLAN selection should really use information from the client certificate (in case of EAP-TLS) instead.
Ugh. OK.
If someone is willing to write a submission for this, it would be very useful to be able to use information from various certificate attributes to decide what to do with the request after the EAP-TLS authentication has been completed. This would make it possible to disable check_cert_cn and would even allow use of groups (i.e., not just list of every possible identity string) for VLAN assignment.
Yes. The idea is to set up callbacks after the client cert has been received, to allow dynamic expansion of certificate attributes on request. The main issue in doing that is figuring out how to take the SSL context (buried inside of the EAP code), and make it available when the dynamic expansion code is called... Alan DeKok.