Hi Gabriel,
Thanks for the feedback!
I believe that the "...matching server-SUFFIX.dom.org" is the same as
what I referred to as our support for "...funky wildcard matching
(http://tinyurl.com/2h33hp)".
Those wild-cards are specified in the server-certs, but you're
mentioning a configuration file for alias/wild-card matching rules (?).
I'd be hesitant to support additional matching in relying party-specific
matching rules. It would be very GT-specific as the browsers do not
support any of that.
My hope was to mimic as much of the browser functionality as possible,
take "rfc2818 - 3.1. Server Identity" as the blue print, and leave it at
that.
We would basically just allow the server-cert to specify a list of
host-name aliases.
Do you have any use cases that would "desperately" need additional
matching capabilities?
Regards, Frank.
Gabriel Mateescu wrote:
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
--
Frank Siebenlist [EMAIL PROTECTED]
The Globus Alliance - Argonne National Laboratory
