(In reply to comment #0)
> We should also consider introducing randomness into the proxy certificate
> serial number when we do this. I will explain why in a separate bug report.

Bug 6614 

(In reply to comment #0)
> 2) Should we migrate to SHA-1 algorithm or SHA-2 (those seem to be the obvious
> choices)? SHA-1 is starting to show weakness already, but SHA-2 support is not
> ubiquitous yet and may not be in older versions of OpenSSL. The correct
> question here is probably: what does not support SHA-2 that we care about?

Quoting from
http://www.mail-archive.com/cryptography@metzdowd.com/msg10143.html

Nearly everything I've seen regarding the proposed solutions to this
attack have involved migration to SHA-1.  SHA-1 is scheduled to be
decertified by NIST in 2010, and NIST has already recommended[1] moving
away from SHA-1 to SHA-2 (256, 512, etc.).  Collision attacks have
already been demonstrated[2] against SHA-1 back in 2005, and if history
tells us anything then things will only get worse for SHA-1 from here.
By not moving directly to at least SHA-2 (until the winner of the NIST
hash competition is known), these vendors are likely setting themselves
up for similar attacks in the (relatively) near future.

[1] http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html
[2] http://www.cryptography.com/cnews/hash.html

The OpenSSL we ship with 4.0.x does not include the SHA-2 variants. For 4.2.x
we use the system-supplied OpenSSL, but it looks like there are API functions
in OpenSSL to look up digest methods by name, so we can determine at runtime
what is supported by the system without relying on the preprocessor in either
case. It looks like the proxy API has hooks for specifying a signing algorithm
as an attribute to the GSI-specific structure, but only SHA-1 is allowed in the
actual signing code.

I propose we add a new environment variable to the security configuration:
GLOBUS_GSI_PROXY_DIGESTS with the value being a colon-separated of OpenSSL
digest names (default being "SHA256:SHA1:MD5". If a  proxy used for
authentication is signed by something other than one of those, it will be
rejected. If a proxy is signed by one of those and we don't have runtime
support for it, it will also be rejected. When the code signs a proxy, it'll
use the first one in the list which is supported by the runtime. It can be
overridden by setting the proxy handle attribute to a different digest method.

Also, add a command-line option to grid-proxy-init to choose the hash by name
to explicitly override the environment/default values.

There are also some bits in the WS-Security code which use signing, but that
will be for another bug if we want to address that.

CoG JGlobus is the relevant module for this on Java GSI. It appears that SHA1
and SHA2 are supported by the libraries used for proxy creation. The current
Java API does not allow choosing of the algorithm but uses the signing
algorithm from the issuing certificate. Additional API can be added to override
this. Quick review of API, I could not find any way to dynamically detect
supported algorithms, but need to investigate some more.

Like Joe mentions, if support is needed in WS Security, code in wsrf module
needs to be modified.

Hi Joe.

I am worried that we will get a compatibility mess with your proposal.

For example, the OpenSSL on SL4 and SL5 seems not to support SHA2.
So if a user has a machine with a more "advanced" OpenSSL library that does
support it, and create a proxy with with SHA2-based signature, this proxy will
be useless on most of OSG (as an example).

Since SHA2 will be the Globus default on that platform, the user will be
surprised, at the very least.

I think we need to agree on a hash algorithm and make sure we can use it on all
the supported platforms. Else, we will get into one of the following scenarios:
a) a complete mess (like descried above)
b) people will learn to use the common denominator... and once people start
putting things like
grid-proxy-init -hash md5 
in their scripts, it will take forever to change that.

My 2c,
  Igor

I think the right solution here is to do what the Java side already does,
namely:

The current Java API does not allow choosing of the algorithm but uses the
signing algorithm from the issuing certificate.

Basically, whatever the algorithm is used to sign the EEC is used for all
subsequent proxy certificates. This puts the migration firmly in the hands of
the deployers and GT will follow along with any future migration as the CAs
migrate to SHA2 (which they presumably won't do until OpenSSL fully supports
it). If a deployer doesn't want to trust a particular algorithm, it falls on
them to not trust any CA issuing with that algoritm. 

That's easy enough to implement. Are the CAs consistent enough in how they have
been signing things to make this an effective way to disallow MD5?

In addition to  the signature of the certificate itself, the ProxyCertInfo
extension is signed. Currently the GSI C code hardcodes SHA1 signatures. I
assume this should also match the issuer certificate digest algorithm?

Actually, I misread the code, the other SHA1 hash is used to generate the
serial number of the proxy certificate.

(In reply to comment #9)
> Actually, I misread the code, the other SHA1 hash is used to generate the
> serial number of the proxy certificate.

Ah, good. I was concerned there for a moment. 

We should also take up the serial number under Bug 6614 

I committed an implementation of "use issuer's cert signing algorithm" based on
the 4.2 branch to the bug_6613_4_2_branch CVS branch. See
http://viewcvs.globus.org/viewcvs.cgi/gsi/proxy/proxy_core/source/library/globus_gsi_proxy.c?r1=1.33.2.1&r2=1.33.2.1.2.1&pathrev=bug_6613_4_2_branch
http://viewcvs.globus.org/viewcvs.cgi/gsi/gssapi/source/library/accept_delegation.c?r1=1.37&r2=1.37.12.1&pathrev=bug_6613_4_2_branch
http://viewcvs.globus.org/viewcvs.cgi/gsi/gssapi/source/library/accept_sec_context.c?r1=1.34&r2=1.34.8.1&pathrev=bug_6613_4_2_branch
for the patches.

There currently are no test cases for the proxy_core API at all, so we can
either rely on the higher-level tests or spend some time writing tests for that
API.

The patches I posted yesterday don't address question #3 yet from the original
post. Does it make sense to add an environment setting of "hashes I trust"?
Current GSI-C proxies are md5 even if the cert is signed with sha1.

(In reply to comment #12)
> The patches I posted yesterday don't address question #3 yet from the original
> post. Does it make sense to add an environment setting of "hashes I trust"?
> Current GSI-C proxies are md5 even if the cert is signed with sha1.

Without rendering an opinion, let me lay forth some thinking on the matter.

My thinking is that a deployer can with the patch control what hashes they
accept by controlling what CAs they accept. If they don't want to accept MD5
hashes, don't accept any CAs that sign EECs with MD5.

A couple places where that won't work:

1) A CA that has EECs signed with different hashes. Probably for historical
reasons. I know of no such CA today.

2) When there is a mix of patched and unpatched GSI, which can result in a user
whose EEC is signed with (e.g.) SHA1 but takes a path through legacy GRAM or
SSH and ends up presenting a MD5-signed proxy. E.g. they GSI-SSH to host A with
a SHA-1-signed EEC, but using an old SSH client which delegates a MD5-signed
PC, and then connect via GSI-SSH to host B.

(In reply to comment #12)
> The patches I posted yesterday don't address question #3 yet from the original
> post. Does it make sense to add an environment setting of "hashes I trust"?
> Current GSI-C proxies are md5 even if the cert is signed with sha1.

I propose we go ahead and roll the algorithm inheritance Joe has implemented
out as soon as possible. I believe that is a major step forward for C
implementation security and the sooner we get it out the better.

With regards to a configuration option for "hashes I trust" I propose we
consider that as a separate issue (i.e. create another bug for it) and see what
feedback and requirements we get from the user community. I think we still have
enough time with MD5 we are better off thinking this over a little.

Patch committed to 4.2 and 4.0 branches and trunk, so that the proxy is signed
with the same digest that signed the issuing certificate, but there is no
strict enforcement that this is the case.

Joe

(In reply to comment #4)
> CoG JGlobus is the relevant module for this on Java GSI. It appears that SHA1
> and SHA2 are supported by the libraries used for proxy creation. The current
> Java API does not allow choosing of the algorithm but uses the signing
> algorithm from the issuing certificate. Additional API can be added to override
> this. Quick review of API, I could not find any way to dynamically detect
> supported algorithms, but need to investigate some more.

I'm seeing problems with jglobus when using SHA-2 certificates. PureTLS appears
to not support SHA-2. I opened Bug 6730 to track it.