This email describes a proposal to change the current host-authorization
processing in our different GT-clients (GT2, GT4, myproxy-init, gridftp,
etc.).
The end result would be a host-authorization processing that would
enable a more dynamic use of host dns mappings, and provide a migration
path to a (slightly) more secure form of host authorization that doesn't
rely on dns lookups.
Most of the discussions about the need for the reverse dns lookup have
been documented "over the years", and this "reverse dns feature" has
been discussed in many bars all over the world:
http://bugzilla.globus.org/globus/show_bug.cgi?id=318
http://bugzilla.globus.org/globus/show_bug.cgi?id=1753
Note that the proposed changes have not been implemented (yet), and
we're looking for feedback, thumbs up/down, comments, suggestions, etc.
Current host-authz processing
-----------------------------
Our current host-authorization processing works as follows:
1) client has a target network endpoint reference, like
"https://svc.acme.com/app";
2) client extract the dns-name "svc.acme.com", and uses dns to lookup
the ipaddress, e.g. "svc.acme.com=>123.12.1.3"
3) client does a reverse dns lookup to find the host-name for the
ipaddress, which may be different (alias) from the initial target's dns
name: "123.12.1.3=>www.acme.com"
4) client initiates an ssl/tls connection with the server at
"123.12.1.3", and expect a server certificate with the host-name
"www.acme.com", i.e. host authz yields permit if cert's subject(altname)
somehow matches the host-name.
Issues with current host-authz scheme
-------------------------------------
There are two issues with the current scheme:
1) (insecure) dns is used for the alias to host-name mapping
This scheme allows the client to use dns aliases for the target server,
while using (insecure) dns to provide the alias mapping.
By relying on dns, it exposes itself to possible compromises that use
dns spoofing attacks. At the time this was concocted, a trade-off was
made between usability and security, and the user communities were very
much driving those requirements.
http://bugzilla.globus.org/globus/show_bug.cgi?id=1753
DNS Spoofing techniques
http://www.securesphere.net/download/papers/dnsspoof.htm
If there is interest then I could give examples of more detailed
compromise scenarios.
2) relies on reverse dns mapping entries for deployment
The reverse dns entries are not needed for the ip-address resolution,
but are required for the alias=>host-name lookup.
(Reverse DNS Overview - https://www.dyndns.com/support/kb/reverse_dns.html)
We have a number of deployment scenarios where it is difficult to
administer the reverse dns entries, because the service-owners lack the
rights to do so. For example, if Alice wants to run a service in her own
account on a server, then normally she does not have access to the host
credentials. One option would be for Alice to define her own alias for
the host through a dynamic dns service, like alice-svc.dyndns.org. Alice
could run a service on a non-privileged port, like
"https://alice-svc.dyndns.org:4567/svc";, and could obtain a separate
host/server certificate for the hostname "alice-svc.dyndns.org" such
that clients can use ssl to authN&authZ Alice's service/server.
Another example is running a server on your laptop and connecting
through different ISPs as you travel. In those cases the laptop owner
could use dyndns.org to obtain a stable host-name and an associated
server-cert, but she will not be able to administer the reverse dns
entries as those are maintained by the different ISP-dns servers.
Lastly, we have scenarios where servers themselves are dynamically and
ad-hoc created as they are instantiated on virtual machines. Again, one
could dynamically create dns names, hostname=>ip-address mappings, and
even the host-certs, but the reverse mappings are an issue.
In short, the requirement to have a reverse dns mapping entry makes some
of the more "flexible" deployments of servers very cumbersome and even
impossible, while there is no need for any reverse mapping from a
network end point resolution point of view nor from a host-authz point
of view.
Proposed changes and path forward
---------------------------------
In an ideal world, I believe that the client should only look at the
hostname that it received in the initial network endpoint for the
service and compare that with the name in the presented server-cert,
and forget the reverse lookup all together ... but that would break
backwards compatibility as it wouldn't allow the use of aliases for the
target, and would result in unhappy users...
A possible backwards compatible solution with a migration path to a more
secure deployment option, would consist of the following efforts:
1) change the processing of the host authorization such that first the
hostname in the client's initial network endpoint is matched with the
host-cert presented by the service during the ssl-handshake. If that
matches, then all is ok and no need for any reverse dns lookup. This
would allow for easier use of host-certs in dhcp/dyndns deployments.
2) only if the hostname match failed in 1), do the reverse dns-lookup to
find an alias hostname like we currently do. This would take care of the
backwards compatibility as those that rely on it will not notice the
change made in processing sequence.
3) make step 2) optionally through a config parameter such that those
that do not want to rely on insecure-dns at all can turn it off.
4) add support in the client path validation for multiple hostnames to
be entered in the subjectAltName extension of an X.509 certificate
(rfc2818 - 3.1. Server Identity: "http://www.ietf.org/rfc/rfc2818.txt";).
Currently we support some funky wildcard matching
(http://tinyurl.com/2h33hp), but we do not support a list of hostnames
in the certificate. By adding that support, it should make it easier to
support the secure use of hostname aliases, and communities can migrate
to such a deployment scheme over time.
In short, the proposed changes in the host-authz processing would allow
for a more flexible use of dns hostname mapping, by default it would be
backwards compatible with what we have now such that it shouldn't break
any current deployments that rely on dns hostname aliases, it would
optionally disable the reliance on the dns reverse lookup, and finally
would offer a more secure alternative for the dns alias support through
server certs with multiple hostnames.
Comments?
Securely yours, Frank.
--
Frank Siebenlist [EMAIL PROTECTED]
The Globus Alliance - Argonne National Laboratory
