Bug 4994 – Depth limit of 9 for proxy credentials - intentional, or no?

Bug 4994 - Depth limit of 9 for proxy credentials - intentional, or no?

Summary:

Depth limit of 9 for proxy credentials - intentional, or no?

Status:	RESOLVED FIXED

Product:	GSI C
Component:	Credentials and Proxies
Version:	4.0.3
Platform:	Macintosh All

Importance:	P3 normal
Target Milestone:	4.2.0
Assigned To:	Rachana Ananthakrishnan

URL:
Keywords:	4.0.x

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2007-02-06 14:18 by Charles Bacon
Modified:	2008-12-10 11:00 (History)

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From Charles Bacon 2007-02-06 14:18:41

There was a report to the mailing list that the C code won't verify proxies
at/past depth 9:
http://www.globus.org/mail_archive/gt-user/2007/01/msg00178.html

The same report mentions that WS service will also start failing after about
depth 20.  The user mentions where the check is happening (we don't call
SSL_CTX_set_verify_depth, and 9 is the default), and I assume the Java side is
some BouncyCastle default.

Is this intentional?  It has started biting people on the TeraGrid who use
Gsi-Openssh a lot.  After enough logins across nodes, their delegated
credential is too deep to verify to gridftp or pre-ws GRAM.  What can/should we
do about this?

------- Comment #1 From Von Welch 2007-02-06 14:30:46 -------

No, it is not intentional. There is a mechanism to limit proxy delegation depth
(defined in RFC 3820), but AFAIK no one has every employed it. I assume this is
some hard-coded limit on either chain length (in terms of number of
certificates) or chain size (in terms of bytes) in some software.

The only solutions I can think of are: (1) fix the code, or (2) use myproxy to
transform a long-chained proxy into a fresh EEC.

Jim Basney mentioned this has also been an issue in EGEE I believe where they
have a number of service layers in place. I think he also said they are using
myproxy as I mention above to work around it.

------- Comment #2 From Jim Basney 2007-02-06 14:58:48 -------

Hidemoto Nakada (AIST) talked to me (and others) about this problem at OGF19. 
They see it when doing interop testing with EGEE, because there are a lot of
proxy hops when translating between EGEE's gLite and NAREGI.

Please do fix the code.  There should be no limit on the certificate chain
length by default, in my opinion.

------- Comment #3 From David Carver 2007-02-08 17:10:05 -------

Here is the error message from "gsissh -vvv" for the depth limit user proxy
problem:

OpenSSL Error: s3_srvr.c:2010: in library: SSL routines, function
SSL3_GET_CLIENT_CERTIFICATE: no certificate returned
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Can't get the local trusted CA certificate

Here is a link that Charles also pointed me to that has a better explanation of
the error:

http://www.globus.org/mail_archive/gt-user/2007/01/msg00178.html

The routine �ssl_verify_cert_chain� in
source-trees/gsi/openssl_gpt/ssl/s3_srvr.c needs to report a less generic error
message than �no certificate returned�.  This problem was not obvious from the
error message.

------- Comment #4 From Jim Basney 2007-06-13 12:44:53 -------

Fix for C code committed to trunk:

  http://www.globus.org/mail_archive/csec-commit/2007/06/msg00000.html

------- Comment #5 From Joe Bester 2008-12-10 11:00:24 -------

Merged this back to the 4.0 branch. It should be available in 4.0.9.