A question has arisen about the reference to RFC 2818 section 3.1 within Section 5.3: When performing this comparison implementations MUST follow the validation rules specified in [RFC2818] Section 3.1. In the case of the server this involves ensuring the certificate presented by the EAP-TLS peer was intended to be used as a client certificate. Implementations SHOULD use the Extended Key Usage (see [RFC3280] Section 4.2.1.13) extension and ensure that at least one of the following is true: 1) The certificate issuer included no Extended Key Usage identifiers in the certificate. 2) The issuer included the anyExtendedKeyUsage identifier in the certificate (see [RFC3280] section 4.2.1.13). 3) The issuer included the id-kp-clientAuth identifier in the certificate (see [RFC3280] section 4.2.1.13). Here is the text from that reference: 3.1. Server Identity In general, HTTP/TLS requests are generated by dereferencing a URI. As a consequence, the hostname for the server is known to the client. If the hostname is available, the client MUST check it against the server's identity as presented in the server's Certificate message, in order to prevent man-in-the-middle attacks. If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) In such cases, it is important to narrow the scope of acceptable certificates as much as possible in order to prevent man in the middle attacks. In special cases, it may be appropriate for the client to simply ignore the server's identity, but it must be understood that this leaves the connection open to active attack. If a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead. Matching is performed using the matching rules specified by [RFC2459]. If more than one identity of a given type is present in the certificate (e.g., more than one dNSName name, a match in any one of the set is considered acceptable.) Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. In some cases, the URI is specified as an IP address rather than a hostname. In this case, the iPAddress subjectAltName must be present in the certificate and must exactly match the IP in the URI. If the hostname does not match the identity in the certificate, user oriented clients MUST either notify the user (clients MAY give the user the opportunity to continue with the connection in any case) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it. Note that in many cases the URI itself comes from an untrusted source. The above-described check provides no protection against attacks where this source is compromised. For example, if the URI was obtained by clicking on an HTML page which was itself obtained without using HTTP/TLS, a man in the middle could have replaced the URI. In order to prevent this form of attack, users should carefully examine the certificate presented by the server to determine if it meets their expectations. Overall, this reference does seem to have some relevance to the issues discussed in Section 5.3. In terms of relevance to EAP-TLS, there is typically no URL. In some cases EAP-TLS server hostname and IP address are not known before authentication, and so cannot be compared to the Server-Id (e.g. 802.11), but in other cases this might be possible (e.g. VPN). Paragraphs 5-6 seem relevant, but paragraph 7 is probably not relevant. Given this, my inclination is to keep the reference to RFC 2818, but make it normative (since there is a MUST reference to it).
_______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
