Please review the following proposal and discuss it on this thread. RFC 5216 lacks guidance on how to validate the EAP server's certificate especially with respect to identities.
RFC 5216 recommends validating the certificate path is valid and that the extended key usage attributes are either not present, allow for any usage or allow for TLS server usage. This creates an issue that if the same truest root is used for EAP TLS and for other TLS server usage that any TLS server will be able to extend its privilege and behave as an EAP server. The following recommendations are made for implementations and deployments to avoid this problem. 1. EAP TLS Peer implementations SHOULD allow for configuration of names to match against SANs of type DNS name that are authorized to act as EAP-TLS servers. 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU specified in RFC 3770. EAP TLS peer implementations SHOULD allow for the configuration to require the id-kp-eapOverLAN EKU for validation of EAP server certificates. 3. If the above options are not available then separate trust roots need to be used to issue certificates for EAP-TLS server and for TLS servers. EAP TLS peer implementations MUST allow for configuration of a unique trust root to validate the server's certificate. EAP-TLS peer implementations SHOULD provide ways to automate the configuration of the information necessary for the validation of the certificate. Cheers, Joe
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
