[csec-user] STRICT_RFC2818 enforcement in globus-url-copy

[Venkat Yekkirala]

[CC'ing csec-user]

Joe,

It's good that you should bring up the hostname here. It's leading in
the direction I was hoping it would :)

One other "issue" I have noticed is that if I pass the hostname into
gsi/gssapi using the new GLOBUS_GSS_C_NT_HOST_IP type name, I see gsi/gssapi
will NOT perform the revese-DNS lookup even when I force STRICT_GT2. It will
only perform the lookup if I passed in an IP address using the GLOBUS_GSS_C_NT_HOST_IP.
This seems like a bug to me.

Further GLOBUS_GSS_C_NT_HOST_IP does NOT allow me to specify a
service name (or does it?). So, I am forced to use GSS_C_NT_HOSTBASED_SERVICE
if I want to specify the service name using the @ prefix to the hostname.

I am basically looking for a way to perform the following:

1. I pass in either a hostname or an IP address (but NOT both together
since the user would have specified only one or the other and we must
not allow gsi/gssapi to use a "derived" hostname or IP address when
in STRICT_RFC2818 mode) with an optional service name.

2. GSI/GSSAPI does the comparisons as documented on the below mentioned
page, performing a reverse-DNS lookup as needed REGARDLESS OF WHETHER IT
WAS A HOSTNAME OR AN IP ADDRESS THAT WAS PASSED IN:
http://www.globus.org/toolkit/docs/5.0/5.0.3/security/gsic/developer/#gsic-env-name

Unless I missed something it doesn't look like there's a name type I
could use for item 1 above. I am forced to either use GSS_C_NT_HOSTBASED_SERVICE
(ability to specify the service name but no IP address or reverse-DNS support)
or GLOBUS_GSS_C_NT_HOST_IP (support for IP address and reverse-DNS but can't
specify service name).

I am likely opening a can of worms here but I guess the goal is for all GT
components to standardize on "one way" here which is how the below started:
http://bugzilla.mcs.anl.gov/globus/show_bug.cgi?id=318

----- Original Message -----
> I think this is a gridftp bug, not a GSI bug. The code is not passing
> the hostname into the gssapi stack, but doing it's own lookups based
> on the ip address. I've contacted the gridftp developers.
> 
> On Mar 9, 2011, at 12:29 PM, Venkat Yekkirala wrote:
> 
> > One missing addition below.
> >
> > ----- Original Message -----
> >> Joe,
> >>
> >> In working on
> >> http://bugzilla.mcs.anl.gov/globus/show_bug.cgi?id=6789
> >> I have been doing limited testing of globus-url-copy.
> >>
> >> I find that even when I have GLOBUS_GSSAPI_NAME_COMPATIBILITY set
> >> to
> >> STRICT_RFC2818 globus-url-copy still does the reverse-DNS lookup
> >> and
> >> sends the resultant name as the target_name to
> >> gss_init_sec_context().
> >>
> >> Below is my test scenario:
> >>
> >> On pkilab2.ncsa.uiuc.edu:
> >>
> >> ysvenkat at pkilab2:~$ export
> >> X509_USER_CERT=/home/ysvenkat/.globus/myCA/hostcert.pem
> >> ysvenkat at pkilab2:~$ export
> >> X509_USER_KEY=/home/ysvenkat/.globus/myCA/hostkey.pem
> >> ysvenkat at pkilab2:~$ export GRIDMAP=/etc/grid-security/grid-mapfile
> >> ysvenkat at pkilab2:~$ globus-gridftp-server -debug
> >> Server listening at pkilab2.ncsa.uiuc.edu:51034
> >>
> >>
> >> On holodeck (the client):
> >>
> >> holodeck:~ ysvenkat$ echo $GL
> >> /Users/ysvenkat/gt5.0.3
> >> holodeck:~ ysvenkat$ which globus-url-copy
> >> /Users/ysvenkat/gt5.0.3/bin/globus-url-copy
> >> holodeck:~ ysvenkat$
> >> holodeck:~ ysvenkat$ cat /etc/hosts
> >> ##
> >> # Host Database
> >> #
> >> # localhost is used to configure the loopback interface
> >> # when the system is booting. Do not change this entry.
> >> ##
> >> 127.0.0.1 localhost
> >> 255.255.255.255 broadcasthost
> >> ::1 localhost
> >> fe80::1%lo0 localhost
> >> 141.142.234.15 pkilab2.ncsa.uiuc.edu venkat.ncsa.uiuc.edu
> >> holodeck:~ ysvenkat$
> >> holodeck:~ ysvenkat$ env | grep COMPAT
> >> GLOBUS_GSSAPI_NAME_COMPATIBILITY=STRICT_RFC2818
> >> holodeck:~ ysvenkat$ globus-url-copy
> >> gsiftp://venkat.ncsa.uiuc.edu:51034//home/ysvenkat/y9
> >> file:///Users/ysvenkat/y9.1
> >> holodeck:~ ysvenkat$ host pkilab2
> >> pkilab2.ncsa.uiuc.edu has address 141.142.234.15
> >> pkilab2.ncsa.uiuc.edu mail is handled by 100
> >> amantadine.ncsa.uiuc.edu.
> >> pkilab2.ncsa.uiuc.edu mail is handled by 100
> >> rimantadine.ncsa.uiuc.edu.
> >> pkilab2.ncsa.uiuc.edu mail is handled by 500 mail.ncsa.uiuc.edu.
> >> holodeck:~ ysvenkat$
> >>
> >> Stepping thru gdb shows that
> >
> > globus_l_ftp_control_send_cmd_cb()
> >
> >
> >> invokes
> >> globus_gss_assist_authorization_host_name("141.142.234.15")
> >> to do the reverse-DNS lookup so the user-specified host name
> >> venkat.ncsa.uiuc.edu (which is a
> >> /etc/hosts alias of pkilab2.ncsa.uiuc.edu as you can see in the
> >> above)
> >> ends up being resolved
> >> to pkilab2.ncsa.uiuc.edu and this latter name being used by
> >> gss_compare_name().
> >>
> >> I have the server using the below cert. Is the above behavior
> >> intended? If so,
> >> how can the user control whether a reverse-DNS lookup is done or
> >> not?
> >> I see there's
> >> a -s option I could use to specify a subject name beginning with a
> >> /
> >> but what if
> >> I don't want to use the option, but want the reverse-DNS lookup to
> >> NOT
> >> be done?
> >>
> >> I have some other questions/comments that are sort of dependent on
> >> my
> >> understanding
> >> this (non?) issue better.
> >>
> >> Thanks.
> >>
> >> ysvenkat at pkilab2:~$ openssl x509 -text -noout -in
> >> .globus/myCA/hostcert.pem
> >> Certificate:
> >> Data:
> >> Version: 3 (0x2)
> >> Serial Number:
> >> c1:90:9b:5f:7b:f5:33:d5
> >> Signature Algorithm: sha1WithRSAEncryption
> >> Issuer: C=US, ST=Illinois, O=Internet Widgits Pty Ltd, OU=NCSA,
> >> CN=MYCA/emailAddress=ysvenkat at ncsa.uiuc.edu
> >> Validity
> >> Not Before: Feb 11 17:00:30 2011 GMT
> >> Not After : Feb 11 17:00:30 2012 GMT
> >> Subject: C=US, ST=Illinois, L=Urbana, O=Internet Widgits Pty Ltd,
> >> OU=NCSA, CN=host/pkilab2.ncsa.uiuc.edu
> >> Subject Public Key Info:
> >> Public Key Algorithm: rsaEncryption
> >> Public-Key: (1024 bit)
> >> Modulus:
> >> 00:ce:7e:66:b5:3f:11:11:50:90:3d:55:28:e9:ed:
> >> 7f:24:98:7a:68:5e:6d:ff:01:96:1a:ad:b4:d2:ad:
> >> c8:04:f9:33:1f:71:14:4c:42:f8:59:e6:77:33:c7:
> >> c0:f3:55:af:1e:39:68:db:b6:39:12:3c:e0:ff:68:
> >> 72:6a:18:5f:70:c6:1c:b5:15:bd:bc:65:64:5e:6a:
> >> 08:5f:af:eb:a9:ae:af:37:61:36:a1:f8:3c:44:3b:
> >> 90:bc:24:00:d6:d9:f1:0c:13:22:82:35:61:66:07:
> >> ff:e3:32:f3:a3:8b:44:a7:33:4b:50:f4:e3:76:5f:
> >> c5:f2:b5:43:3a:2c:73:d8:d3
> >> Exponent: 65537 (0x10001)
> >> X509v3 extensions:
> >> X509v3 Basic Constraints:
> >> CA:FALSE
> >> Netscape Comment:
> >> OpenSSL Generated Certificate
> >> X509v3 Subject Key Identifier:
> >> DF:45:72:A2:09:51:2D:8E:4D:CF:45:F4:AF:57:9E:E4:41:06:24:6D
> >> X509v3 Authority Key Identifier:
> >> keyid:F6:34:28:97:41:9F:29:1B:60:82:FA:F1:84:6D:B8:E1:FB:F1:0A:6A
> >>
> >> Signature Algorithm: sha1WithRSAEncryption
> >> 61:1b:3f:d8:20:20:ba:c2:71:de:9e:3a:ae:48:66:10:ab:36:
> >> c2:37:c5:ee:1f:39:fc:41:0e:4e:15:7a:0b:d2:90:1e:5b:c9:
> >> e2:66:c1:68:93:47:42:98:ad:24:57:0e:e6:1b:88:41:89:80:
> >> 95:0d:b5:57:59:01:c7:2f:52:9d:2a:42:f3:53:69:85:75:5d:
> >> e5:ac:14:27:c8:d6:37:c3:e6:8c:27:67:e1:33:0b:9e:f2:7c:
> >> f2:71:e2:10:6c:09:f1:c8:1d:09:91:20:35:d7:de:00:45:b5:
> >> 9f:82:8e:7e:97:0b:58:84:7d:f9:ef:0f:f3:37:6e:5c:ab:1c:
> >> ae:4c
> >> ysvenkat at pkilab2:~$