Subject: Re: [authmeth] secure derivations of server hostname

From: Michael Ströder <[email-masked]>
Date: Mon, 30 Jun 2003 19:49:07 +0200

Roger Harrison wrote:
> I can't provide some examples, because I'm not sure what, precisely, Bob 
> had in mind when he made his suggestion.

Without the rationale and some real-world examples I'm rather scared to 
relax the checking of the server's hostname in any way.

Ciao, Michael.

  Bob, can you give us some
> insight here?
>  
> Thanks,
>  
> Roger
> 
>  >>> Michael Ströder <[email-masked]> 6/29/2003 6:44:54 AM >>>
> Roger Harrison wrote:
>  > There is an outstanding work item, G.25, in authmeth-05 regarding
>  > the use of derived forms of the server's name when performing a the
>  > server identity check while processing a StartTLS request. Currently,
>  > the wording of section 4.1.6 says:
>  >
>  > "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 other derived
>  > form of name including the server's canonical DNS name."
>  >
>  > According to my notes, Bob Morgan offered to provide some wording that
>  > would relax this restriction to allow usage of derivations of the server
>  > name that are provided securely. If Bob or some other knowledgeable
>  > member of the WG would help me with the proper wording or some
>  > information about what is acceptable, I will make the needed changes and
>  > close out the work item.'
> 
> Could you please give some examples of "derivations of the server
> name that are provided securely"? Is this about using host names in X.509v3
> subjectAltName extension? I'm rather scared about relaxing this since I
> suspect that unsecure DNS is used to get the derivation of the server name.
> 
> Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 30 Jun 2003 11:40:41 -0700

I'll give two examples.

1) a client could derive a hostname from "localhost" in a secure fashion.
2) a client could derive a hostname from a domain name in a secure fashion
   using DNSSEC.

I know of implementations doing 1).

Kurt

At 10:49 AM 6/30/2003, Michael Ströder wrote:
>Roger Harrison wrote:
>>I can't provide some examples, because I'm not sure what, precisely, Bob had in mind when he made his suggestion.
>
>Without the rationale and some real-world examples I'm rather scared to relax the checking of the server's hostname in any way.
>
>Ciao, Michael.
>

---

From: Michael Ströder <[email-masked]>
Date: Mon, 30 Jun 2003 21:53:57 +0200

> 1) a client could derive a hostname from "localhost" in a secure fashion.

How?

> 2) a client could derive a hostname from a domain name in a secure fashion

Yes.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 30 Jun 2003 13:34:28 -0700

>>1) a client could derive a hostname from "localhost" in a secure fashion.

By use of gethostname(3) or the like.

---

From: Michael Ströder <[email-masked]>
Date: Mon, 30 Jun 2003 22:43:28 +0200

> By use of gethostname(3) or the like.

Note that on most systems localhost is rarely the same like the machine's 
host name.

E.g. on a Linux box the interface lo (loopback-device) with IP addr 
127.0.0.1 and name localhost is definitely something different than eth0 
with different IP addr assigned matching the machine's host name.

And not every service binds to all available interface when running on a 
machine.

I see some risks when relaxing the host name check.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Tue, 01 Jul 2003 00:14:53 +0200

Kurt D. Zeilenga wrote:
> 
> And with regards to mappings of "localhost" (or 127.0.0.1 or ::1), I
> view the security considerations to a local matter (that is, it may
> be secure in some environments, not in others).

If it's only secure in a minority of systems that's not a strong argument.

> This 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
>         other derived form of name including the server's canonical DNS name."
> is problematic for a couple of reasons.
> 
> First, it says "the server hostname it used to open the LDAP connection"
> instead of "the server hostname provided by the user (or application
> entity or other trusted entity)".

Yes, the wording should be changed.

> Second, derivation is fine if the result is confirmed by the user.

Well, given all the misconfigured systems today human user are trained to 
happily click away every alert box with "OK" just to step forward. :-/

> So, I'm thinking this should be reworded.
>         The client MUST use the server hostname provided by the user (or other trusted
>         entity) as the value to compare against the server name as expressed in the
>         server's certificate.  A hostname derived from the user input is to be considered
>         provided by the user only if derived in a secure fashion (e.g., DNSSEC) or confirmed
>         by the user.

I'd prefer to drop the note about user confirmation for the reason above. 
IMHO the common work-around with SSL-related dialog boxes appearing all the 
time asking the user for confirmation with most times very unclear language 
should not be mentioned in such a standard.

Ciao, Michael.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 30 Jun 2003 14:49:59 -0700

>I see some risks when relaxing the host name check.

There are certainly risks in use of derived names.  But, I think, the
risks are not so severe to warrant the absolute prohibition of their
use.  DNSSEC can be used to derive a name in secure fashion.  Even
DNS can be used in a secure fashion (e.g., with user confirmation).

This text:

First, it says "the server hostname it used to open the LDAP connection" instead of
"the server hostname provided by the user (or application entity or other trusted entity)".

Kurt