[Pgi-wg] TLS : OpenSSL and GSI implementations - gLite 3.2 released today

[Aleksandr Konstantinov]

On Monday 23 March 2009 15:04, Etienne URBAH wrote:
> To all,
> 
> Concerning various implementations of TLS to handle X509 certificates 
> and proxies, it seems that :
> 
> -  DEISA (Unicore) uses the OpenSSL implementation of TLS to process 
> X509 certificates,
> 
> -  EGEE (gLite) and NorduGrid (ARC) use the GSI (Globus Security 
> Infrastructure) implementation of TLS to process X509 proxies,

No, ARC uses OpenSSL for TLS data connections and Globus for 
GSI connections (SRM and GridFTP).


A.K.


> 
> -  The OpenSSL and GSI implementations of TLS seem to be INCOMPATIBLE 
> (see mails below of Weizhong QIANG and Duane MERRIL).
> 
> This would make any interoperability very difficult.
> 
> 
> But the situation is perhaps NOT so desperate :
> 
> -  EGEE has just released gLite version 3.2 today 23 March 2009.
> 
> -  In slide 3 of the presentation 'Middleware update' performed at CERN 
> GDB on 11 March 2009 and which is available at 
> http://indico.cern.ch/getFile.py/access?sessionId=7&resId=1&materialId=0&confId=45473
>     Andreas UNTERKIRCHER explains that gLite 3.2 uses VDT 1.10, which 
> uses 'system OpenSSL'.
> 
> 
> ==>  Can Andreas UNTERKIRCHER provide more precisions, and confirm that 
> this permits interoperability at the X509 level ?
> 
> ==>  Can the PGI chairs plan an interoperability test ASAP to check if 
> this really work ?
> 
> 
> In hope that the above informations and suggestions are useful.
> 
> Best regards.
> 
> ----------------------------------
> Etienne URBAH          IN2P3 - LAL
> Bat 200     91898 ORSAY     France
> Tel: +33 1 64 46 84 87
> Mob: +33 6 22 30 53 27
> Skype: etienne.urbah
> mailto:urbah at lal.in2p3.fr
> ----------------------------------
> 
> 
> On Mon, 23 Mar 200, Jens Jensen wrote:
> > 2009/3/20 weizhong qiang <weizhongqiang at gmail.com>:
> >> On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel at fz-juelich.de> wrote:
> >> Basically the globus implementation if GSSAPI is about a specific
> >> context-initiation negotiation, and some data-padding for initiation and
> >> data-transferring. Also you can accomplish proxy-delegation via it.
> >> What is for sure is that you can not use client based on normal TLS to talk
> >> with service which is based on GSSAPI, or vice versa.
> >> AFAIK, There is some grid service (WS compliant) such as some SRM service
> >> which uses GSSAPI. (SOAP + HTTP + GSS).
> > 
> > Some years since I last looked at it in detail but IIRC GSSAPI (RFC2743) is just
> > a mechanism for establishing security contexts - if you get these
> > bytes then send
> > this, etc.  Presumably normal TLS can be implemented via GSSAPI as well, see
> > eg section 5.3 of the RFC
> > Someone once told me Globus had to deviate from the standard GSSAPI
> > to implement GSI. If this is true then it's worth documenting, no?
> > Again long time ago I experimented with the Globus module for GSI and
> > the lower level Globus GSSAPI.  At the time they did not interoperate :-)
> > Had some discussions with Aleksandr at the time.
> > 
> > Regards
> > --jens
> 
> 
> 
> On Fri, 20 Mar 2009, Duane Merrill wrote:
> > In theory, rfc-3820 proxy certs should not have any effect on TLS wire 
> > protocol. For various reasons, different versions of GSI-OpenSSH *have* 
> > changed the wire format in different ways. (Shame on them.) Out of 
> > curiosity, are there any published/publicly-availabe descriptions of 
> > these deltas?
> > 
> > Duane
>