Subject: Re: [AuthMeth] server identity check issue

From: "Vithalprasad Gaitonde" <[email-masked]>
Date: Tue, 12 Nov 2002 23:36:50 -0700

Is there an assumption here that the client has connected by hostname only and not by ip address.
If the client has connected by ipaddress, I guess it has to do a reverse lookup and get the hostname. Is this implicit ?
What about multi-homed hosts - hosts with multiple ip address and possibly mulitple DNS names.
e.g. Consider a case of a host configured with 2 ip addresses and separate hostnames for each ip address. In such a case, it the client connects by one hostname (/ipaddress) but gets served by a certificate which has the other hostname. Should the client raise an alert ? 
Is there a way to establish the relation between the two hostnames ? Is the subjectAltName multi-valued or is the server required to have a certificate for each hostname.

Thanks,
Prasad

>>> "Roger Harrison" <[email-masked]> 11/13/02 09:45AM >>>
The following text from [AuthMeth] section 5.1.6 describes the rules for doing the server identity check done during TLS establishment:

- The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate.  The client MUST NOT use the server's canonical DNS name or any other derived form of name.

Problem: I am concerned with this text because it forbids using the server's canonical DNS name to compare against the subjectAltName in the certificate even if the original server hostname used to open the LDAP connection was the canonical DNS name of the server.  I believe the intent of this text was only to forbid comparing a derived form of the server hostname against the server's certificate while specifically warning against transforming into canonical DNS name. 

To resolve this issue, I suggest the following text:

- The client MUST use the server hostname it used to open the LDAP connection as the value to compare against the server name as expressed in the server's certificate.  The client MUST NOT use any derived form of the server hostname for this comparison (including the server's canonical DNS name if the original server hostname is not the server's canonical DNS name)

I would appreciate comments and feedback on this proposed change to the text.

Also, I have had comments asking what the difference is between a server's DNS hostname and a server's canonical DNS hostname.  Frankly speaking, I had to do a bit of research to understand this myself, and I would not be surprised if this fairly common. I would appreciate any feedback as to whether we should give additional information explaining this distinction or if we should assume that readers will know enough (or be able to learn enough) about DNS to deal with this without explanation.

Sincerely,

Roger

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 13 Nov 2002 21:24:27 -0800

>Is there an assumption here that the client has connected by hostname only and not by ip address.

Yes.  The document should like address this.

>If the client has connected by ipaddress,

ipAddress names should likely be examined per RFC 2459. 

>I guess it has to do a reverse lookup and get the hostname.  Is this implicit ?

No derived values should be used (for security reasons).

>What about multi-homed hosts - hosts with multiple ip address and possibly mulitple DNS names.

I believe multiple ipAddress names can be associated with a certificate.

>e.g. Consider a case of a host configured with 2 ip addresses and separate hostnames for each ip address. In such a case, it the client connects by one hostname (/ipaddress) but gets served by a cer…

If a domain name is used, that domain should appear as a certificate subject.
If a IP address is used, that address should appear as a certificate subject.

>Is there a way to establish the relation between the two hostnames ?

All the (verified) names which the entity is known by can be represented in the
certificate.

>Is the subjectAltName multi-valued or is the server required to have a certificate for each hostname.

It's a SEQUENCE of names.

I note that, in a related issue, that we should clarify whether DNS wildcards
apply to dNSname and CN fields, or just dNSname fields, or just CN fields.
Personally, I think they only apply to dDNSname fields.