Dear all, Last step we must add a security consideration section as mentioned by Greg :
De : "Greg Newby" <newby@arsc.edu> Date : 28 mars 2011 08:15:48 HAEC À : Eddy Caron <Eddy.Caron@ens-lyon.fr>
... "Unfortunately nobody noticed earlier that you had not included a security considerations section. This is one of the requirements -- take a look at GFD #152 for discussion & example. I'm sorry for not pointing this out when the document was originally submitted." ... See www.ggf.org/documents/GFD.152.pdf for all information. I checked in the last SAGA-API document (because we are close to the behavior) and I propose the following update from the Andre's paragraph to be compliant to the GridRPC document. Security Considerations As the GRPC API is to be implemented on different types of Grid (and Cloud) middleware, it does not specify a single security model, but rather provides hooks to interface to various security models. A GRPC implementation is considered secure if and only if it fully supports (i.e. implements) the security models of the middleware layers it builds upon, and neither provides any (intentional or unintentional) means to by-pass these security models, nor weakens these security models’ policies in any way. The implementations of advert services (the “backend” services to this API), need to take security concerns into account, because such a service might cause leaks of user (meta) data beyond the runtime of the applications using this API. This is the same risk as with storage and file systems, to which the GRPC Data Management core API provides an API. Unlike with established file systems, however, the risks associated with advert services might be less obvious to their implementors. Andre can I use your text as based ? No strong copyright on it ? :-) If someone from the GridRPC-WG have some remarks, constraints or additional information, let me know or update the CVS. Best Regards, Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------
On Mar 29, 2011, at 3:53 AM, Eddy Caron wrote:
Dear all,
Last step we must add a security consideration section as mentioned by Greg :
De : "Greg Newby" <newby@arsc.edu> Date : 28 mars 2011 08:15:48 HAEC À : Eddy Caron <Eddy.Caron@ens-lyon.fr>
... "Unfortunately nobody noticed earlier that you had not included a security considerations section. This is one of the requirements -- take a look at GFD #152 for discussion & example. I'm sorry for not pointing this out when the document was originally submitted." ...
See www.ggf.org/documents/GFD.152.pdf for all information.
I checked in the last SAGA-API document (because we are close to the behavior) and I propose the following update from the Andre's paragraph to be compliant to the GridRPC document.
Security Considerations
As the GRPC API is to be implemented on different types of Grid (and Cloud) middleware, it does not specify a single security model, but rather provides hooks to interface to various security models. A GRPC implementation is considered secure if and only if it fully supports (i.e. implements) the security models of the middleware layers it builds upon, and neither provides any (intentional or unintentional) means to by-pass these security models, nor weakens these security models’ policies in any way.
This is good. Can you stop here?
The implementations of advert services (the “backend” services to this API),
Does this apply to GridRPC? Do you have "advert services"?
need to take security concerns into account, because such a service might cause leaks of user (meta) data beyond the runtime of the applications using this API. This is the same risk as with storage and file systems, to which the GRPC Data Management core API provides an API. Unlike with established file systems, however, the risks associated with advert services might be less obvious to their implementors.
Andre can I use your text as based ? No strong copyright on it ? :-)
If someone from the GridRPC-WG have some remarks, constraints or additional information, let me know or update the CVS.
Best Regards, Eddy ---------------------------------------------------------------------------------------------- Eddy Caron. Mcf ENS Lyon ENS Lyon - LIP - Projet GRAAL 46 Allee d'Italie, 69364 Lyon Cedex 07, France E-Mail : Eddy.Caron@ens-lyon.fr [ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ] ------------------------------------------------------------------------------------------------
-- gridrpc-wg mailing list gridrpc-wg@ogf.org http://www.ogf.org/mailman/listinfo/gridrpc-wg
-- Daniel S. Katz University of Chicago (773) 834-7186 (voice) (773) 834-3700 (fax) d.katz@ieee.org or dsk@ci.uchicago.edu http://www.ci.uchicago.edu/~dsk/ -- Daniel S. Katz University of Chicago (773) 834-7186 (voice) (773) 834-3700 (fax) d.katz@ieee.org or dsk@ci.uchicago.edu http://www.ci.uchicago.edu/~dsk/
Hi Eddy, sure I am fine with copying the security section from the SAGA spec! :-) I agree with Dan though that the reference to the advert service seems to be confusing without the SAGA context. Just a proposal, but you might want to change
The implementations of advert services (the “backend” services to this API), need to take security concerns into account, because such a service might cause leaks of user (meta) data beyond the runtime of the applications using this API. This is the same risk as with storage and file systems, to which the GRPC Data Management core API provides an API. Unlike with established file systems, however, the risks associated with advert services might be less obvious to their implementors.
into The implementation of GridRPC services (the “backend” services to this API) need to take security concerns into account, because such a service might cause leaks of user (meta) data. That is similar to risks associated with other known data managing services, but risks associated with GridRPC services might be less obvious to their implementors and users. Hope that helps, Andre. On Tue, Mar 29, 2011 at 10:53 AM, Eddy Caron <Eddy.Caron@ens-lyon.fr> wrote:
Dear all, Last step we must add a security consideration section as mentioned by Greg :
De : "Greg Newby" <newby@arsc.edu> Date : 28 mars 2011 08:15:48 HAEC À : Eddy Caron <Eddy.Caron@ens-lyon.fr>
... "Unfortunately nobody noticed earlier that you had not included a security considerations section. This is one of the requirements -- take a look at GFD #152 for discussion & example. I'm sorry for not pointing this out when the document was originally submitted." ... See www.ggf.org/documents/GFD.152.pdf for all information. I checked in the last SAGA-API document (because we are close to the behavior) and I propose the following update from the Andre's paragraph to be compliant to the GridRPC document. Security Considerations As the GRPC API is to be implemented on different types of Grid (and Cloud) middleware, it does not specify a single security model, but rather provides hooks to interface to various security models. A GRPC implementation is considered secure if and only if it fully supports (i.e. implements) the security models of the middleware layers it builds upon, and neither provides any (intentional or unintentional) means to by-pass these security models, nor weakens these security models’ policies in any way. The implementations of advert services (the “backend” services to this API), need to take security concerns into account, because such a service might cause leaks of user (meta) data beyond the runtime of the applications using this API. This is the same risk as with storage and file systems, to which the GRPC Data Management core API provides an API. Unlike with established file systems, however, the risks associated with advert services might be less obvious to their implementors.
Andre can I use your text as based ? No strong copyright on it ? :-) If someone from the GridRPC-WG have some remarks, constraints or additional information, let me know or update the CVS. Best Regards, Eddy ----------------------------------------------------------------------------------------------
Eddy Caron. Mcf ENS Lyon
ENS Lyon - LIP - Projet GRAAL
46 Allee d'Italie, 69364 Lyon Cedex 07, France
E-Mail : Eddy.Caron@ens-lyon.fr
[ Tel : 04.37.28.76.46 ][ Web page : http://graal.ens-lyon.fr/~ecaron ]
------------------------------------------------------------------------------------------------
-- So much time, so little to do... [Garfield]
participants (3)
-
Andre Merzky -
Daniel S. Katz -
Eddy Caron