Subject: Re: A comment on certificate-based server authentication and multiple DNS names

From: [email-masked]
Date: Wed, 6 Sep 2000 14:53:20 +0000

[email-masked] wrote:
>[email-masked] writes:
>
>> There is however a problem when a single server host may respond to
>> more than one DNS name. This problem is analogous to the one in
>> initial versions of the HTTP protocol, which made it impossible to
>> serve multiple domains from a single IP number.
>
>I don't see this as big problem; I don't think people usually do large
>scale "virtual hosting" for ssh. There's no problem if you can assign
>one ip-number for each name, and the reason people can't always do
>that for http is that they have quite a large number of names for a
>single machine say (a web hosting service with with 100+ customers).
>
  I don't think you're giving the protocol the credit it deserves. SSH's
utility is not limited to providing a secure login, the basic feature of
connection multiplexing with end-to-end flow control is useful for many
other applications.
  Even if you do limit the scope to secure login applications, the current
specification would make it unduly difficult for IPP (Internet Presence
Provider) VARs to provide a secure login to their virtual domains,
especially since ARIN is clamping down on IP allocations for virtual
hosting (see http://whois.arin.net/announcements/policy_changes.html). It
also seems as though RIPE is allocating address ranges for virtual hosting
only on the condition that they be returned once HTTP 1.1 is "widely
deployed" (see http://www.ripe.net/ripencc/tips/http.html).

>>   Now, it would be entirely possible to devise a new key exchange
scheme,
>> which would carry the DNS name the client intends to connect to, in
order
>> to allow the server host to select the corresponding private key and
>> certificate to respond with. However, it seems that it might be possible
to
>> extend the current diffie-hellman-group1-sha1 in a backwards compatible
>> manner to include an optional string parameter in the DH_INIT packet:
>>
>>   byte      SSH_MSG_KEXDH_INIT
>>   mpint     e
>>   string    server dns name (optional)
>
>I prefer not adding complexity to security protocols.

  I agree, but the utility and the relatively low additional complexity of
this addition justify it in my mind.

>If one really
>wants to do this, one should also consider whether or not the name
>should be included in the definition exchange hash.
>
  I don't think that should be necessary, since the only purpose of the DNS
name parameter is to allow the server to select the correct private key to
use for generating the exchange signature and the certificate to include in
the DH response. The certificate will then provide a binding/reference to
the DNS name (or some other attribute that identifies the destination).

>There's also a client-side way to solve the problem: Have an option to
>the client that looks up a "canonical name" for the host (whatever
>that means: following CNAMES in DNS, or performing reverse-lookup on
>the ip-address of the target, or some such), and if it differs from
>the hostname as written by the user, the client will
>
>  (i) display the canonical name to the user, and
> (ii) use that name when verifying certificates.
>
  This is assuming that there is a such a thing as a canonical name for the
host. A common setup for virtual hosting is to have multiple A-records
point to the same IP address, and the majority of reverse domains are
misconfigured (see http://sc.menandmice.com/).
  This is also assuming that there's a user sitting at the originating end
of the connection, again limiting the utility of the protocol for other
applications than interactive, secure logon.

>/Niels
>
>PS. Your mail looked quite anonymous, with a from address of
>"[email-masked]" and no name or .signature. I can't say if that a
>clinet.fi mailing-list problem, a Lotus Notes problem, or a local
>oz.is configuration error?

  How quaint. I don't use a signature, but the from address should be
correct.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 06 Sep 2000 12:33:41 -0400

Current SSH 1.x has the problem:
    1) it can not cope with load balanced machines. I.e. if I 
    ssh to "smtp.example.com" and that has multiple A records, then
    I may get warnings when I log into a different box than last time.
    Unless, I synchronize the host keys, which I may not wish to do.

    2) it can not cope with different port numbers. I use modified
    sshd on a different port number to access a custom chroot jail.

    3) I may need to SSH to "www.example.com" to administrate the system.
    SSH is happy to permit multiple names to map to the same A record right
    now. If www.example.com moves to a different physical box, then I get
    warned (which is good). But, I don't have to guess which system it is
    currently on. So, people *do* do virtual hosting with SSH. They use 
    it to administrate the systems on which they do virtual hosting.
    Further, consider use of SFTP for uploading of web content!

  Current SSH Oy SSH 2 implementations now record port numbers and stuff.
They do not as I recall record name->IP mappings. This is implementation 
stuff.

  If there is something in the protocol that prevents a server from serving
multiple mappings of name->IP addresses, then there is a problem. (I don't
understand the problem though)

   :!mcr!:            |  Cow#1: Are you worried about getting Mad Cow Disease?
   Michael Richardson |  Cow#2: No. I'm a duck.
 Home: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[email-masked]</A>. PGP key available.

---

From: [email-masked] (Niels M�ller)
Date: 11 Sep 2000 10:27:17 +0200

Appearantly, there are some more issues here than I was aware of when
I wrote my previous article on the subject...

>     Unless, I synchronize the host keys, which I may not wish to do.

If the clients are to be unaware that smtp.example.com is actually
several distinct machines, they will get confused if they randomly get
different hostkeys when connecting to that. The current ssh practice
and implementations more or less requires "One machine, one host key".

Perhaps one could record several keys in the known_hosts database.

(Another solution is to have a master key for the "virtual machine"
smtp.example.com, and use that key to create certificates for the
individual machines. But that will probably not work and interoperate
in practice for some time to come).

>     sshd on a different port number to access a custom chroot jail.

That's a bug, I would say. If it's fixed in SSH Oy SSH2 (as you say
below), that's good.

> They do not as I recall record name->IP mappings. This is implementation 

It's probably a bad idea to record ip-numbers.

> understand the problem though)

As I understand it, the problem occurs if:

1. A server hosts both foo.example.com and bar.example.com, using the
   same ip-number and port.

2. One wants to use distinct host keys for the two names, say FOOKEY
   and BARKEY.

When a client connects, the server has to choose to use one of the
keys to prove its autenticity. If the client believes it is connecting
to "bar.example.com", the server has to use BARKEY, else FOOKEY.
However, the server doesn't have enough information to make the right
choice.

The suggestion is to add somthing similar to the http host:-header to
some early keyexchange packet. I'm not yet conviced that is a good
idea.

/Niels

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Sep 2000 12:46:44 -0400

>>>>> "Niels" == Niels Möller <[email-masked]> writes:
    Niels> If the clients are to be unaware that smtp.example.com is actually
    Niels> several distinct machines, they will get confused if they randomly get
    Niels> different hostkeys when connecting to that. The current ssh practice
    Niels> and implementations more or less requires "One machine, one host key".

    Niels> Perhaps one could record several keys in the known_hosts database.

    Niels> (Another solution is to have a master key for the "virtual machine"
    Niels> smtp.example.com, and use that key to create certificates for the
    Niels> individual machines. But that will probably not work and interoperate
    Niels> in practice for some time to come).

  The index can be:
      name, IP-address, port => host-key

  Yes, it would be good to have such a certificate eventually.
  In another revision of the spec.

    >> sshd on a different port number to access a custom chroot jail.

    Niels> That's a bug, I would say. If it's fixed in SSH Oy SSH2 (as you say
    Niels> below), that's good.

  Yes, it is mostly. I just wanted to remind that this use.

    >> They do not as I recall record name->IP mappings. This is implementation 

    Niels> It's probably a bad idea to record ip-numbers.

  I disagree. I care if the name->IP mapping chanes as much as I change 
that the host key changes. In fact, the host key may have changed because
the name->IP mapping changed.

    Niels> As I understand it, the problem occurs if:

    Niels> 1. A server hosts both foo.example.com and bar.example.com, using the
    Niels>    same ip-number and port.

    Niels> 2. One wants to use distinct host keys for the two names, say FOOKEY
    Niels>    and BARKEY.

    Niels> When a client connects, the server has to choose to use one of the
    Niels> keys to prove its autenticity. If the client believes it is connecting
    Niels> to "bar.example.com", the server has to use BARKEY, else FOOKEY.
    Niels> However, the server doesn't have enough information to make the right
    Niels> choice.

    Niels> The suggestion is to add somthing similar to the http host:-header to
    Niels> some early keyexchange packet. I'm not yet conviced that is a good
    Niels> idea.

  I see.
  I do not support the idea of multiple host keys per host.
  HTTPS has the same problem, btw.

  My solution above of name,IP-address -> key solves this problem.

---

From: [email-masked] (Niels M�ller)
Date: 12 Sep 2000 10:57:31 +0200

>       name, IP-address, port => host-key

...

>   My solution above of name,IP-address -> key solves this problem.

I believe you solve a different problem. There are a few different
cases:

1. Single/multiple names, single ip, single hostkey (default
   operation, no problem)

2. Multiple names, multiple ip, multiple hostkeys. This flavour of
   "virtual hosting" should also be no problem, just have one ssh
   daemon listening on each ip. If we compare to https, in this case
   it works with no problem.

3. Multiple names, single ip, multiple hostkeys. This is where a
   host-header-equivalent would help, while recording ip-numbers is
   useless. This is exactly the same problem as with https "ip-less
   virtual hosting".

4. Single name, multiple ip, multiple hostkeys. This is the
   load-balancing case. Recording ip-numbers would help here.

/Niels

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 12 Sep 2000 13:36:04 -0400

[wg chair hat off]

Certificates bind a name to a key; they don't just say "this is an ssh
host key", they say, "this is lysator.liu.se's ssh host key".

The client, when verifying a server's certificate, needs to make sure
that the name supplied by the end-user and the/a name in the server's
certificate match..

If we add certificates to the mix, we need to split this case:

   1a.  single name, single ip, single hostkey, single cert.

   1b.  multiple names, single ip, single hostkey, multiple names in certificate.

   1c.  multiple names, single ip, single hostkey, multiple certificates.

					- Bill

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Sep 2000 15:56:02 -0400

>>>>> "Niels" == Niels Möller <[email-masked]> writes:
    Niels> I believe you solve a different problem. There are a few different
    Niels> cases:

  Good description.

    Niels> 1. Single/multiple names, single ip, single hostkey (default
    Niels> operation, no problem)

    Niels> 2. Multiple names, multiple ip, multiple hostkeys. This flavour of
    Niels> "virtual hosting" should also be no problem, just have one ssh
    Niels> daemon listening on each ip. If we compare to https, in this case
    Niels> it works with no problem.

    Niels> 3. Multiple names, single ip, multiple hostkeys. This is where a
    Niels> host-header-equivalent would help, while recording ip-numbers is
    Niels> useless. This is exactly the same problem as with https "ip-less
    Niels> virtual hosting".

    Niels> 4. Single name, multiple ip, multiple hostkeys. This is the
    Niels> load-balancing case. Recording ip-numbers would help here.

  I suggest that having multiple host keys is not that important.

  HTTPS has a big problem with #3 because they can not present multiple
names with the same certificate. As SecSH does not yet deal in certificates,
I suggest that the problem should be solved at that point.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 12 Sep 2000 16:45:32 -0400

> I suggest that the problem should be solved at that point.

There is "insert certificate here" text in the current set of drafts.

					- Bill

---

From: Bill Manning <[email-masked]>
Date: Wed, 13 Sep 2000 03:34:41 -0700 (PDT)

% The client, when verifying a server's certificate, needs to make sure
% that the name supplied by the end-user and the/a name in the server's
% certificate match..
% 
%    1. Single/multiple names, single ip, single hostkey (default
%       operation, no problem)
% 
% If we add certificates to the mix, we need to split this case:
% 
%    1a.  single name, single ip, single hostkey, single cert.
% 
%    1b.  multiple names, single ip, single hostkey, multiple names in certificate.
% 
%    1c.  multiple names, single ip, single hostkey, multiple certificates.
% 
% 					- Bill

	1d. single name, multiple ip, .... :)

-- 
--bill