Hi,
Looks like a good idea.
I would add the following functionality:
Clients should support configurable hostname matching.
For example, assume the network endpoint reference is
server.dom.org
Then it should be possible to match this with the received CN
server1.dom.org
using some kind of matching expressions in a configuration file.
This would be a generalization of the GSI host-based authentication
in which server.dom.org was matching server-SUFFIX.dom.org.
Speaking of this suffix rule, it is not clear to me if it also supported
by the Java core (in addition of the C GSI).
Regards,
Gabriel
On Jan 8, 2008, at 8:06 AM, Frank Siebenlist wrote:
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
