Hello, I would really enjoy if these chances are made into reality. Reverse DNS is something that took me minutes to set on my first experiences with Globus. And if you don't administrative rights to the DNS server, it is a source of headaches. Thanks for the info, Frank.
[]'s On Jan 9, 2008 2:02 PM, Frank Siebenlist <[EMAIL PROTECTED]> wrote: > Just wanted to share the attached posting from a different list to > foster discussion. > > -Frank. > > > -- > Frank Siebenlist [EMAIL PROTECTED] > The Globus Alliance - Argonne National Laboratory > > Dear all, > > 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. > > I'm really, really happy that this will finally be put right (if all goes > fine). Apart from supporting the use cases that Frank mentioned explicitly > below, it also addresses the major issue I've had with the reverse-DNS hack > in managing large setups: the inability to use DNS CNAMEs to manage > services instead of physical machines also in the data centre setting. > Whereas it is customary to use DNS aliases for web servers, mail servers, > etc. this was never possible for GridFTP servers or derived products > (such as resource brokers and the like). For this reasons, file catalogues > all over the world are polluted with physical host names that site > administrators can now never change again. > In this case, there is no issue of "not being able to control" the > reserve DNS map, but just that there is no "proper" mapping to begin with. > > > Also, using only the "forward" DNS mapping, and relying on the dNSName > attribute in SubjectAltName, is well supported by all current (IGTF > accredited) > CAs, as subjectAltName's dNSName has been a mandatory attribute for all > host and service certificates since 2003. This means that all CAs support > it, and (virtually) all of them will be able to add *multiple* dNSName > attributes to the subjectAltName to address the "multiple NIC name" > issues that were AFAIK the reason for implementing the reverse-DNS-hack > in the first place. This addresses: > > > ... but that would break > > backwards compatibility as it wouldn't allow the use of aliases for the > > target, and would result in unhappy users... > > since, once these changes have been implemented, the GT toolsk will > act like all modern web browser client in recognising multiple dNSNames > in subjectAltName when matching the certificate to the FQDN used > in the local URL. > > For me, in short: please go this way (as soon as reasonably possible)! > > Best, > DavidG. > > > > > > 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. > > > > > > -- __________________________________ João Marcelo Uchôa de Alencar Computer Science BSc. jmarcelo.alencar(at)gmail.com Linux User 398939 __________________________________
