Subject: [Emu] RFC 2818 reference

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 May 2007 15:09:52 -0700

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-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 8 May 2007 15:51:14 -0700

So would the section be revised to clarify when 2818 would be
applicable, such as when the hostname and DNS are known ahead of time?

________________________________

	From: Bernard Aboba [mailto:[email-masked]] 
	Sent: Tuesday, May 08, 2007 3:10 PM
	To: [email-masked]
	Subject: [Emu] RFC 2818 reference

	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). 

	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).