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

Wed Mar 9 19:04:42 CST 2011

Attached is a patch to globus_ftp_control to make globus-url-copy and 
other apps using our ftp libraries compliant.  This may change depending 
on how Joe plans to address your comments.

Mike

On Wed 3/9/2011 1:04 PM, Venkat Yekkirala wrote:
> [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:~$
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug6331_ftp_control.patch
Type: text/x-patch
Size: 4177 bytes
Desc: not available
URL: <http://lists.globus.org/pipermail/csec-user/attachments/20110309/9c43082c/attachment.bin>