Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
Hi, ok let's put it as follows: I meant "proxy-based TLS == GSI" - maybe a bit simplified but isn't it clear in the context here? But we can talk about GSI then... Yeah GridFTP is an important service but indeed with no WS-interface, so out of scope here. What do you think about the "either-or" dependency to nail it down more precisely. Take care, 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: Thursday, March 19, 2009 3:51 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
hi, I think the issue you proposed can be divided into branches (since HTTPS is actually http + tls/ssl): 1. If all of the PGI services use SOAP (i.e. Web Service interface)? 2. If all of the PGI services use TLS? For the first one, at least GridFTP service is excluded, while it is widely used by production grid. For the second, maybe most of the services are based on secure transportcommunication, but some of them are using GSI (SRM service: SOAP + GSI?)
In terms of ARC, the A-REX service (for job management, supporting BES,JSDL) is using SOAP plus TLS, while it is also configurable to support SOAP plus GSI.
Regards, Weizhong
2009/3/19 Morris Riedel <m.riedel@fz-juelich.de>
Hi security folks,
reading certain elements of the IIRM, strawman, and following discussions> on the list - I see there is still no common agreement on SOAP / HTTP(S) in some areas.
### Goal:
(a) We are discussing if SOAP / HTTPS can be used in PGI to contact a functional interface (like BES)...
(b) ...because we want to find out if there is any important service in the PGI context that is not capable of using SOAP (over SSL layer)...
(c) ... in order to find out if we can agree on SOAP/HTTPS or to understand> requirements from other non WS-based interfaces in PGI.
Therefore the aim of this thread is to get to an agreement in this context, while considering Attribute authorities like VOMS as a supportive service and not an functional interface (also separate thread).
### Contacting functional implementations with SOAP
If we consider the case that we communicate with an functional interface> like OGSA-BES - we agree on SOAP.
### TLS/SSL Layer:
# <strawman> Foundational: Conveying identity for authentication. SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using a SSL/TLS transport protocol in which endpoints are mutually authenticated by X.509 end-entity public key certificates (PKCs). # </strawman>
# <simple plumbings: authentication> We use authentication either based on identities inside X.509 end-entity public key certificates or X.509 proxies (including restrictions, encoding handled separately in another thread).
This refers of using either one or the other of these certificate types on the SSL/TLS level.
For simplification of the profile - there should be no direct dependencies> with attribute-transport used for authorization. # </plumbings>
### Possible scenarios:
# A. TLS with end-entity certificate, SOAP in message -> authN check with CA
# B. TLS with (restricted) proxy certificates, SOAP in message - authN check with proxy signer chain
### Possible Conclusion:
# We use SOAP inside a message to contact functional interfaces.
# We use either full X.509 end-entity certificates OR X.509 proxies (with restrictions)
### Open Questions:
Q: There are WS interfaces for functional specifications that matter to PGI (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree on SOAP based on HTTPS as mentioned above?
Q: If not - are there any important functional interfaces (except support interfaces from AAs like classic VOMS) that do not support SOAP in the PGI ecosystem?
Please feel free to comment but let the question of attributes+restrictions> outside - I propose to deal with it in separate threads because of their complexity.
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)
_______________________________________________ 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 Thu, Mar 19, 2009 at 6:27 PM, <m.riedel@fz-juelich.de> wrote:
Hi,
ok let's put it as follows: I meant "proxy-based TLS == GSI" -
"proxy-based TLS" could also be normal TLS (only difference it that you need to check the delegation chain when verifying; the newer version of openssl itself has supported this, or you can also customize the verifying process of openssl with older version to support verification of delegation chain). Of cause GSI is also "proxy-based TLS". But I thinks it is not compatible to normal TLS since it use GSIAPI which has some specific protocol.
maybe a bit simplified but isn't it clear in the context here? But we can talk about GSI then...
Yeah GridFTP is an important service but indeed with no WS-interface, so out of scope here.
What do you think about the "either-or" dependency to nail it down more precisely.
I did not understand this point. Weizhong
Take care, 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: Thursday, March 19, 2009 3:51 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
hi, I think the issue you proposed can be divided into branches (since HTTPS is actually http + tls/ssl): 1. If all of the PGI services use SOAP (i.e. Web Service interface)? 2. If all of the PGI services use TLS? For the first one, at least GridFTP service is excluded, while it is widely used by production grid. For the second, maybe most of the services are based on secure transportcommunication, but some of them are using GSI (SRM service: SOAP + GSI?)
In terms of ARC, the A-REX service (for job management, supporting BES,JSDL) is using SOAP plus TLS, while it is also configurable to support SOAP plus GSI.
Regards, Weizhong
2009/3/19 Morris Riedel <m.riedel@fz-juelich.de>
Hi security folks,
reading certain elements of the IIRM, strawman, and following discussions> on the list - I see there is still no common agreement on SOAP / HTTP(S) in some areas.
### Goal:
(a) We are discussing if SOAP / HTTPS can be used in PGI to contact a functional interface (like BES)...
(b) ...because we want to find out if there is any important service in the PGI context that is not capable of using SOAP (over SSL layer)...
(c) ... in order to find out if we can agree on SOAP/HTTPS or to understand> requirements from other non WS-based interfaces in PGI.
Therefore the aim of this thread is to get to an agreement in this context, while considering Attribute authorities like VOMS as a supportive service and not an functional interface (also separate thread).
### Contacting functional implementations with SOAP
If we consider the case that we communicate with an functional interface> like OGSA-BES - we agree on SOAP.
### TLS/SSL Layer:
# <strawman> Foundational: Conveying identity for authentication. SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using a SSL/TLS transport protocol in which endpoints are mutually authenticated by X.509 end-entity public key certificates (PKCs). # </strawman>
# <simple plumbings: authentication> We use authentication either based on identities inside X.509 end-entity public key certificates or X.509 proxies (including restrictions, encoding handled separately in another thread).
This refers of using either one or the other of these certificate types on the SSL/TLS level.
For simplification of the profile - there should be no direct dependencies> with attribute-transport used for authorization. # </plumbings>
### Possible scenarios:
# A. TLS with end-entity certificate, SOAP in message -> authN check with CA
# B. TLS with (restricted) proxy certificates, SOAP in message - authN check with proxy signer chain
### Possible Conclusion:
# We use SOAP inside a message to contact functional interfaces.
# We use either full X.509 end-entity certificates OR X.509 proxies (with restrictions)
### Open Questions:
Q: There are WS interfaces for functional specifications that matter to PGI (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree on SOAP based on HTTPS as mentioned above?
Q: If not - are there any important functional interfaces (except support interfaces from AAs like classic VOMS) that do not support SOAP in the PGI ecosystem?
Please feel free to comment but let the question of attributes+restrictions> outside - I propose to deal with it in separate threads because of their complexity.
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)
_______________________________________________ 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 ------------------------------------------------------------------- -------------------------------------------------------------------
Embedded comments.... 2009/3/19 weizhong qiang <weizhongqiang@gmail.com>
On Thu, Mar 19, 2009 at 6:27 PM, <m.riedel@fz-juelich.de> wrote:
Hi,
ok let's put it as follows: I meant "proxy-based TLS == GSI" -
"proxy-based TLS" could also be normal TLS (only difference it that you need to check the delegation chain when verifying; the newer version of openssl itself has supported this, or you can also customize the verifying process of openssl with older version to support verification of delegation chain).
Correct.
Of cause GSI is also "proxy-based TLS". But I thinks it is not compatible to normal TLS since it use GSIAPI which has some specific protocol.
I believe GSI-API is just that, a programming API that conforms to RFC 2744<http://www.faqs.org/rfcs/rfc2744.html> (GSS), and has no protocol restrictions/changes.
On Friday 20 March 2009 15:14, Duane Merrill wrote:
Embedded comments....
2009/3/19 weizhong qiang <weizhongqiang@gmail.com>
On Thu, Mar 19, 2009 at 6:27 PM, <m.riedel@fz-juelich.de> wrote:
Hi,
ok let's put it as follows: I meant "proxy-based TLS == GSI" -
"proxy-based TLS" could also be normal TLS (only difference it that you need to check the delegation chain when verifying; the newer version of openssl itself has supported this, or you can also customize the verifying process of openssl with older version to support verification of delegation chain).
Correct.
Of cause GSI is also "proxy-based TLS". But I thinks it is not compatible to normal TLS since it use GSIAPI which has some specific protocol.
I believe GSI-API is just that, a programming API that conforms to RFC 2744<http://www.faqs.org/rfcs/rfc2744.html> (GSS), and has no protocol restrictions/changes.
I think Weizhong means implmentation of GSIAPI like one from Globus which does have own communication protocol incompatible with TLS. A.K.
I think Weizhong means implmentation of GSIAPI like one from Globus which does have own communication protocol incompatible with TLS.
I don't believe there are any protocol changes between the secure-communication in GSI-API (GSI-OpenSSL) and TLS. As Weizhong mentions, there are additional validation steps in the event that GSI detects the presence of a proxy-extension within a certficate during handshake. But nothing that affects wire protocol. -Duane
On Fri, Mar 20, 2009 at 2:14 PM, Duane Merrill <dgm4d@virginia.edu> wrote:
Embedded comments....
2009/3/19 weizhong qiang <weizhongqiang@gmail.com>
On Thu, Mar 19, 2009 at 6:27 PM, <m.riedel@fz-juelich.de> wrote:
Hi,
ok let's put it as follows: I meant "proxy-based TLS == GSI" -
"proxy-based TLS" could also be normal TLS (only difference it that you need to check the delegation chain when verifying; the newer version of openssl itself has supported this, or you can also customize the verifying process of openssl with older version to support verification of delegation chain).
Correct.
Of cause GSI is also "proxy-based TLS". But I thinks it is not compatible to normal TLS since it use GSIAPI which has some specific protocol.
I believe GSI-API is just that, a programming API that conforms to RFC 2744 <http://www.faqs.org/rfcs/rfc2744.html> (GSS), and has no protocol restrictions/changes.
The globus implementation if GSSAPI (I suppose it should be the only candidate we are discussing about in out context) does use some specific negotiation protocol and some "padding" data when doing security context initiation and data transferring, which is not compatible to normal TLS/SSL. Weizhong
GSI encompasses MyProxy, Delegation Service, Community Authorization Service. GSI does not include binding of attribute certificates within PKCs or PCs. So GSI is an overlapping but different set of features than we are talking about right here. Besides, to my knowledge, GSI supports vanilla PKCs as well as PCs. -Duane On Thu, Mar 19, 2009 at 1:27 PM, <m.riedel@fz-juelich.de> wrote:
Hi,
ok let's put it as follows: I meant "proxy-based TLS == GSI" - maybe a bit simplified but isn't it clear in the context here? But we can talk about GSI then...
Yeah GridFTP is an important service but indeed with no WS-interface, so out of scope here.
What do you think about the "either-or" dependency to nail it down more precisely.
Take care, 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: Thursday, March 19, 2009 3:51 pm Subject: Re: [Pgi-wg] Sec: Agreement on SOAP and authentication
hi, I think the issue you proposed can be divided into branches (since HTTPS is actually http + tls/ssl): 1. If all of the PGI services use SOAP (i.e. Web Service interface)? 2. If all of the PGI services use TLS? For the first one, at least GridFTP service is excluded, while it is widely used by production grid. For the second, maybe most of the services are based on secure transportcommunication, but some of them are using GSI (SRM service: SOAP + GSI?)
In terms of ARC, the A-REX service (for job management, supporting BES,JSDL) is using SOAP plus TLS, while it is also configurable to support SOAP plus GSI.
Regards, Weizhong
2009/3/19 Morris Riedel <m.riedel@fz-juelich.de>
Hi security folks,
reading certain elements of the IIRM, strawman, and following discussions> on the list - I see there is still no common agreement on SOAP / HTTP(S) in some areas.
### Goal:
(a) We are discussing if SOAP / HTTPS can be used in PGI to contact a functional interface (like BES)...
(b) ...because we want to find out if there is any important service in the PGI context that is not capable of using SOAP (over SSL layer)...
(c) ... in order to find out if we can agree on SOAP/HTTPS or to understand> requirements from other non WS-based interfaces in PGI.
Therefore the aim of this thread is to get to an agreement in this context, while considering Attribute authorities like VOMS as a supportive service and not an functional interface (also separate thread).
### Contacting functional implementations with SOAP
If we consider the case that we communicate with an functional interface> like OGSA-BES - we agree on SOAP.
### TLS/SSL Layer:
# <strawman> Foundational: Conveying identity for authentication. SOAP over HTTPS (PGI_HTTPS). SOAP-over-HTTP communication using a SSL/TLS transport protocol in which endpoints are mutually authenticated by X.509 end-entity public key certificates (PKCs). # </strawman>
# <simple plumbings: authentication> We use authentication either based on identities inside X.509 end-entity public key certificates or X.509 proxies (including restrictions, encoding handled separately in another thread).
This refers of using either one or the other of these certificate types on the SSL/TLS level.
For simplification of the profile - there should be no direct dependencies> with attribute-transport used for authorization. # </plumbings>
### Possible scenarios:
# A. TLS with end-entity certificate, SOAP in message -> authN check with CA
# B. TLS with (restricted) proxy certificates, SOAP in message - authN check with proxy signer chain
### Possible Conclusion:
# We use SOAP inside a message to contact functional interfaces.
# We use either full X.509 end-entity certificates OR X.509 proxies (with restrictions)
### Open Questions:
Q: There are WS interfaces for functional specifications that matter to PGI (BES, WS-DAIS and SRM) - so in the context of PGI - can we agree on SOAP based on HTTPS as mentioned above?
Q: If not - are there any important functional interfaces (except support interfaces from AAs like classic VOMS) that do not support SOAP in the PGI ecosystem?
Please feel free to comment but let the question of attributes+restrictions> outside - I propose to deal with it in separate threads because of their complexity.
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)
_______________________________________________ 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 ------------------------------------------------------------------- -------------------------------------------------------------------
_______________________________________________ Pgi-wg mailing list Pgi-wg@ogf.org http://www.ogf.org/mailman/listinfo/pgi-wg
participants (4)
-
Aleksandr Konstantinov -
Duane Merrill -
m.riedel＠fz-juelich.de -
weizhong qiang