Updated Java code with the fix. Sam has fixed the C code.

Rachana

What is the fix?

There are probably many users using the dash trick, so you have to be very clear
on how upgrading to GT4 will affect them.

The fix was to no longer allow host-interface.domain to compare successfully
with host.domain. This will break the setup for those people who used this feature.

/Sam

Where is this change documented?  Are we *guaranteeed* that people upgrading
from previous 
versions will find out about it?  Is it in release notes?  Have we documented
what people who depended 
on this should do now that we've "fixed" the feature?  Has anyone consulted our
project liasons to find 
out whether this is going to adversely affect anyone or not?

We should not be making changes that affect features that people have depended
on in the past 
without taking extraordinary measures to communicate that we've made the
change.  I see nothing in 
the comments closing out this bug that such measures have been taken.  Either:

1) Document the communication that is happening here before closing out the
bug, or
2) Figure out what communication needs to be done and do that work before
closing out the bug.

> Where is this change documented?

As far as I know, the feature was never documented in the first place (and
I've never used it for that reason).

This doesn't refute Lee's point; some users are depending on the feature,
and they'll need to be informed.

I would be willing to bet that Keith is right--it wasn't documented, aside from
in the code that Olle 
found.  These are the worst kinds of situations!  I'm quite sure that this
feature was added prior to 
2000, because I think it was there when I started at Argonne in 1999-Dec.  I am
pretty sure that NASA 
was using it then, and may still be. But it was never documented, so we don't
really know whether it's a 
bug or a feature, and thus we don't know whether it's safe to remove it / fix
it or not.  I personally think 
that we should err on the side of caution, because the feature was put there to
support some of the 
large infrastructure deployment projects and changing things now without
investigating what this will 
break could result in some really big downsides.  (Like a big deployment
refusing to move to GT4 until 
we "fix" the "fix.")  But I'm willing to be overruled.

This feature was added by Doug Engert way back, probably prior to GT2. Whether
it was in response to a user request or just of his own invention, I don't know.

Olle has notified the major US and EU PMAs which should reach much of the target
audience.

I believe we need to either remove this or fully support it. I personally vote
for removal, as it's prone to problems.

Below is a blurb I sent to the board regarding this which could be forward to
project leads for further disssemination.

In GT4 we are planning on removing a feature/bug in GT that allowed host names
with dashes to be equivalent to the same hostname without a dash
(e.g. "somehost-eth1.ncsa.uiuc.edu" would equate to
"somehost.ncsa.uiuc.edu"). This feature, which dates back to GT2
at least, was never documented and there have been concerns raised recently
regarding it causing potential security vulnerabilities. Given a choice between
fully documenting and supporting this feature or removing it, we believe the
right choice is to remove it.
http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=2969

Note that my comment was not whether to remove the feature or not, but making
sure it is made clear to users who is upgrading from a previous version. I
suggest to mention it in the migration guides:

http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/developer/migrating_from_gt2.html
http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/developer/migrating_from_gt3.html

as well as in the security chapter of the admin guide:

http://www-unix.globus.org/toolkit/docs/development/4.0-drafts/admin/docbook/ch05.html

This might merit a new Bugzilla entry, but my recommendation would be to update
the documents that 
Mats pointed to (security section of admin guide and the two migration guides),
but rather than just 
"mention the change", actually explain how to handle the host certs and
services for a multi-homed 
system now that you can't use a single host cert.  I don't see anything in
there already on how to deal 
with that scenario, and it seems that we have people in that situation.

Should that be a new Bugzilla entry?

Backed out the change for now.

/Sam

Was this applied to globus_4_0_branch again?

From a Java client:

org.globus.common.ChainedIOException: Authentication failed [Caused by:
Operation unauthorized (Mechanism level: Authorization failed. Expected
"/CN=host/viz-1.isi.edu" target but received
"/DC=org/DC=doegrids/OU=Services/CN=viz-login.isi.edu")]
        at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
        at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:144)


From a C client:

globus_xio_gsi: gss_init_sec_context failed.
GSS Major Status: Unexpected Gatekeeper or Service Name
globus_gsi_gssapi: Authorization denied: The name of the remote host
(viz-login.isi.edu), and the expected name for the remote host (viz-1.isi.edu)
do not match. This happens when the name in the host certificate does not match
the information obtained from DNS and is often a DNS configuration problem.

Matts-

No the code is still in the C code at least. The problem is that it is doesn't
work the way you expect.

From reading the code, the way it works is essentially "hostname" is equivalent
to "hostname-foo", but "hostname-bar" is not equal to "hostname-foo". E.g.:

foo.ncsa.uiuc.edu == foo-bar.ncsa.uiuc.edu
or
foo-1.ncsa.uiuc.edu == foo.ncsa.uiuc.edu

but

foo-1.ncsa.uiuc.edu != foo-bar.ncsa.uiuc.edu

In other words a "-extension" is removed from one hostname or the other before
comparison, but not both.

I am leaving this bug as open as we really need to document this behavior.

That explains why it doesn't work, but does not explain why it used to. I have
been running older version of Globus which used to work on the same machine.

I'm not affected by this bug anymore as we have switched to having a hostcert
for each node (there are only 9). I agree that the behavior should be well
documented.

I cannot find any change in the code back to 1.1 in CVS that would explain
this.
You had the dash in the first part of the hostname right? The only change that
looks like it could be relevant is the following:

revision 1.13
date: 2002/11/01 14:07:10;  author: meder;  state: Exp;  lines: +11 -4
branches:  1.13.2;  1.13.4;  1.13.6;

fix bug in compare name: pitcairn.mcs-foo.anl.gov would compare
favorably with pitcairn.mcs.anl.gov.

Mats,

The current Java code does not match host1-foo and host1-bar, but will match 
host1 and host1-foo. Nothing in commit logs suggest the first case was allowed 
before. Is there a specific version where it worked ? I could try and see if 
there is a branch/tag in jglobus code that allows for it. also, I will add 
notes to the document about this.

Rachana

Hmm, maybe I'm wrong. I do not have the old hostcert anymore, so I can not
verify what the subject really was. I thought it was viz-login.isi.edu and that
worked on viz-{n}.isi.edu, but now I'm not sure anymore.

Discussed with Mats and he hasn't seen any issues since. Closig bug.

A solution to disable the feature by default, but retain it seems like middle 
ground. I am not sure of the implications of this for communities that are 
using it and would appreciate people weighing in on that. If we agree we need 
to make this change, then we can put out a security advisory and update package 
for it.

I think changing default behavior at this point would be a mistake.

I suggest we document current behavior and inform those that feel strongly that
we would be willing to accept a patch allowing the behavior to be disabled.

Current behavior has been documented in "Security considerations" section of 
Pre-ws AA and WS AA. Here is how it looks now:

http://www.globus.org/toolkit/docs/4.0/security/prewsaa/admin-index.html#s-
prewsaa-admin-security_considerations

If we don't want to change default behavior, do we want to allow for a 
configuration to disallow this ? This might make it easier for installations 
where they want this feature disallowed.

I would suggest that if someone wants to be able to disable this behavior, we
should welcome a contribution that allows for such a configuration change.

As part of this campaign
(http://bugzilla.globus.org/globus/show_bug.cgi?id=6331) I added support for
subjectAltName with DNS and/or IP address matching (for GSI C).

There's also an environment variable for disabling this and other non-standard
behaviors (see http://bugzilla.globus.org/globus/show_bug.cgi?id=6331#c1). I'll
update the doc for 4.2.1 where this code will first be public.