Re: Encryption export & Globus Toolkit

["Douglas E. Engert" <deengert@anl.gov>]

So should I go ahead and commit the encryption code to the CVS? You say below 
that it need to be generally available which implies we need to then
release the CVS with these changes.  
 
If the current mods are added as is, encryption will be on.

One of the other options we need to consider at this time, is setting the 
default for the connection. This could be encryption or no encryption. This can 
be done by the client with the the req_flags=GSS_C_CONF_FLAG to gss_init_sec_context.
The two sides then negotiate which cipher to use NULL being the no encryption, but
with integrity and report back to the init/accept via the ret_flags=GSS_C_CONF_FLAG.
The gss_wrap will then use this encryption. It is not easy to change if encryption 
is on or off for different calls to gss_wrap for the same connection. 

I would suggest that if the client may want to use encryption, it
set the req_flags=GSS_C_CONF_FLAG, then the client and server can test
if encryption was negotiate. If encryption is not required the libs will put 
the NULL cipher as first choice. (Currently they set it as the only choice) 
so both sides would find it first. If set, the NULL cipher would not be 
a choice, or would be last if for accept.  
 
                           Server
                       yes      no      either  
                    ---------------------------
        yes         |  yes      reject  yes 
Client  no          |  reject   no      no            
        either      |  yes      no      no
  

The rejects are done be the client and server by testing the ret_flags and making
a choice. Either side can reject. ALso gss_wrap will fail if you ask for encryption 
and it is not available.  

This all needs to be done in a backwards compatible fashion.

As a side note the SSL libs can use an environment variable SSL_CIPHER for
tighter control over the choices and order of ciphers to use. 

Steve Tuecke wrote:
> 
> I have finished the necessary encryption export stuff.  I have gotten the
> necessary legal cover from Argonne legal and the export control manager,
> and on Monday sent the necessary notification of export to BXA (the US
> export control folks).  We can now proceed with:
> 
>    * Adding encryption (message confidentiality) into GSI.
> 
>    * Put both source and binary versions of the Globus Toolkit on our web
> site, including all of the security code.
> 
>    * Make OpenSSL, as is or modified, source or binary, available from our
> web site.
> 
> Note that the key to all of this is that the source code is available free
> of charge to anyone.  The export regulations have special exceptions for
> open source software.  One implication of this is that we need to take a
> little care that any security related code that we provide to outside
> people be made available publicly.  This includes the Globus Toolkit, as
> well as patches to the Globus Toolkit and anything else we might apply
> patches to (e.g. OpenSSL, OpenLDAP, etc).  Freely available to anyone means
> putting it on our web site or anonymous ftp server, either directly or by
> sending it to one of the archived discussion lists such as
> discuss@globus.org.  The main thing to avoid is sending security related
> code to anyone outside the country, without making that code available
> freely to everyone.
> 
> -Steve

-- 

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444