Re: [Pgi-wg] Sec: Agreement on attribute transportmechanismsforAttrAuthZ
Howdy,
-PGI_TLS_PROXY (the notation is also in the virginia strawman) -PGI_GSI
so in this context what is the difference on TLS itself w/o considering different APIs?! Good point in checking this out - I'm still think its rather the same. Thanks for clarification, Morris -------------------------------------------------------------------------------- Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Central Institute of Applied Mathematics Research Centre Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/zam/ZAMPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel 'We work to improve ourselves and the rest of mankind.' ----- Original Message ----- From: weizhong qiang <weizhongqiang@gmail.com> Date: Friday, March 20, 2009 1:10 pm Subject: Re: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ
hi,
PGI_TLS and PGI_GSI were mentioned by you in a few thread. Again, I would like clarify something from my point of view. Do you mean PGI_GSI the services/clients that talk to each other by using GSSAPI? or just talk to each other based on TLS while using proxy certificate. I think there is difference between them. So I would divide them into branch by using your notation: PGI_TLS PGI_TLS_PROXY (the notation is also in the virginia strawman) PGI_GSI
2009/3/20 Morris Riedel <m.riedel@fz-juelich.de>
Hi,
- My personal thinking is, since we are talking about PGI or interoperability, we probably do need to change the current implementation> if it can not satisfy interoperability, while keeping the principle that the change should be as little as possible.
In terms of little changes I agree – but I consider PGI_TLS / PGI_GSI as massive changes.
For instance, we have developed a UNICORE Gateway (for AuthN) that works with PGI_TLS naturally – and PGI_GSI more recently providing of course not FULL delegation support per hop, but proxies are supported on GSI-TLS level.
However, can we expect that you one contact a CREAM-BES any time soon with full end-entity credentials or any other gLite component?
The CREAM service has been tested (by some of our colleagues) . And the result shows CREAM service requires "limited" proxy certificate (proxy with "CN=proxy") when it doing data transfer.
Inherently, because of forwarding mechanisms internally – proxies are
necessary probably.
But maybe that’s my old interop* knowledge – so let’s clarify again…
Some statements that need clarification:
Note: UNICORE can be contacted using PGI_TLS and PGI_GSI – the same is planned for GENESIS-II as far as I remember.
"and PGI_GSI" means PGI_TLS_PROXY or PGI_GSI? From out experience about testing against UNICORE service, it uses PGI_TLS_PROXY.
Q: Do gLite also supports pure PGI_TLS apart from PGI_GSI?
Q: Do ARC also supports pure PGI_TLS apart from PGI_GSI?
PGI_TLS PGI_TLS_PROXY possible to support PGI_GSI (the definition I mentioned)
Q: Do we really imply that PGI-compliance means that both
PGI_GSI and pure
PGI_TLS have to be supported? Or we rather go the plumbing way of defining either or as MANDATORY and as MAY both supported (two plumbings).
I see PGI_TLS_PROXY should be mandatory.
Regards,
Weizhong
Thanks for clarification,
Morris
*From:* Steven Newhouse [Steven.Newhouse@cern.ch] *Sent:* Friday, March 20, 2009 11:49 AM *To:* weizhong qiang; Morris Riedel *Cc:* pgi-wg@ogf.org *Subject:* RE: [Pgi-wg] Sec: Agreement on attribute transport mechanismsforAttrAuthZ
My personal thinking is, since we are talking about PGI or interoperability, we probably do need to change the current
implementation> if it can not satisfy interoperability, while keeping the principle that the
change should be as little as possible.
And to clearly describe the interoperability benefits that will be derived (i.e. systems and communities) by making that change.
Steven
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
------------------------------------------------------------------- ------------------------------------------------------------------- Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDir'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ------------------------------------------------------------------- -------------------------------------------------------------------
On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel@fz-juelich.de> wrote:
Howdy,
-PGI_TLS_PROXY (the notation is also in the virginia strawman) -PGI_GSI
so in this context what is the difference on TLS itself w/o considering different APIs?!
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). Weizhong
Good point in checking this out - I'm still think its rather the same.
Thanks for clarification, Morris
2009/3/20 weizhong qiang <weizhongqiang@gmail.com>:
On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel@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
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, - 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@lal.in2p3.fr ---------------------------------- On Mon, 23 Mar 200, Jens Jensen wrote:
2009/3/20 weizhong qiang <weizhongqiang@gmail.com>:
On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel@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
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@lal.in2p3.fr ----------------------------------
On Mon, 23 Mar 200, Jens Jensen wrote:
2009/3/20 weizhong qiang <weizhongqiang@gmail.com>:
On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel@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
Ok, and that's why we have to support both in our profiles I guess - correct?! Take care, Morris ------------------------------------------------------------ Morris Riedel SW - Engineer Distributed Systems and Grid Computing Division Jülich Supercomputing Centre (JSC) Forschungszentrum Juelich Wilhelm-Johnen-Str. 1 D - 52425 Juelich Germany Email: m.riedel@fz-juelich.de Info: http://www.fz-juelich.de/jsc/JSCPeople/riedel Phone: +49 2461 61 - 3651 Fax: +49 2461 61 - 6656 Skype: MorrisRiedel "We work to better ourselves, and the rest of humanity" Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Vorstand: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender)
------Original Message----- -From: pgi-wg-bounces@ogf.org [mailto:pgi-wg-bounces@ogf.org] On Behalf Of -Aleksandr Konstantinov -Sent: Friday, March 27, 2009 10:49 AM -To: pgi-wg@ogf.org -Subject: Re: [Pgi-wg] TLS : OpenSSL and GSI implementations - gLite 3.2released -today - -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&c onfId=4 -5473 -> 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@lal.in2p3.fr -> ---------------------------------- -> -> -> On Mon, 23 Mar 200, Jens Jensen wrote: -> > 2009/3/20 weizhong qiang <weizhongqiang@gmail.com>: -> >> On Fri, Mar 20, 2009 at 3:00 PM, <m.riedel@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 -> -_______________________________________________ -Pgi-wg mailing list -Pgi-wg@ogf.org -http://www.ogf.org/mailman/listinfo/pgi-wg
participants (7)
-
Aleksandr Konstantinov -
Duane Merrill -
Etienne URBAH -
Jens Jensen -
m.riedel＠fz-juelich.de -
Morris Riedel
-
weizhong qiang