All, Today we discussed which URI's to support in the proposed file staging extensions. Particularly for SC07. I suggest the following URI's ftp http mailto because they do not require us to address the issue of delegation in advance of SC07. (As I said at the last OGF I do not think the delegation approach in the delegation proposal is a good idea). Of course I think ByteIO/RNS is a good idea - but I don't expect much support for that. (We support it.) Note that there exists a standard format for an ftp URI which includes username/password. Therefore one could include the information in the JSDL document without any need for delegation. (I do not know gridFTP well, perhaps it supports a similar set of uri options, eliminating the need for passing a delegated credential.) On the other hand if we choose to support gridFTP, scp, or any other protocol that requires a delegated credential, then we must also agree on a delegation strategy . with a potential need to replace it later. (By the way, we are not familiar with a standard URI format for scp.) Right now we (the Virginia Genesis II group) support ftp, http, mailto, and RNS with delegated credentials (not via the same mechanism Marty is proposing). A
I like a lot of the proposal. But one of the issues here is that none of ftp, http, or mailto is secure. (Note: username/password ftp is still cleartext - not INTO the BES service but rather from the BES service to the FTP service) -- Marty From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Andrew Grimshaw Sent: Thursday, November 01, 2007 1:45 PM To: ogsa-hpcp-wg@ogf.org Subject: [ogsa-hpcp-wg] File staging extension All, Today we discussed which URI's to support in the proposed file staging extensions. Particularly for SC07. I suggest the following URI's ftp http mailto because they do not require us to address the issue of delegation in advance of SC07. (As I said at the last OGF I do not think the delegation approach in the delegation proposal is a good idea). Of course I think ByteIO/RNS is a good idea - but I don't expect much support for that. (We support it.) Note that there exists a standard format for an ftp URI which includes username/password. Therefore one could include the information in the JSDL document without any need for delegation. (I do not know gridFTP well, perhaps it supports a similar set of uri options, eliminating the need for passing a delegated credential.) On the other hand if we choose to support gridFTP, scp, or any other protocol that requires a delegated credential, then we must also agree on a delegation strategy . with a potential need to replace it later. (By the way, we are not familiar with a standard URI format for scp.) Right now we (the Virginia Genesis II group) support ftp, http, mailto, and RNS with delegated credentials (not via the same mechanism Marty is proposing). A
Marty, Marty Humphrey wrote:
I like a lot of the proposal. But one of the issues here is that none of ftp, http, or mailto is secure. (Note: username/password ftp is still cleartext – not INTO the BES service but rather from the BES service to the FTP service)
Are you concerned with the inclusion of the username/password in the URI string in the JSDL or with the fact that the communication channels is unsecured. Even with the secured sftp we would need to add the username/pass to the sftp: URI string. -Vesso
-- Marty
*From:* ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] *On Behalf Of *Andrew Grimshaw *Sent:* Thursday, November 01, 2007 1:45 PM *To:* ogsa-hpcp-wg@ogf.org *Subject:* [ogsa-hpcp-wg] File staging extension
All,
Today we discussed which URI’s to support in the proposed file staging extensions. Particularly for SC07.
I suggest the following URI’s
ftp
http
mailto
because they do not require us to address the issue of delegation in advance of SC07. (As I said at the last OGF I do not think the delegation approach in the delegation proposal is a good idea).
Of course I think ByteIO/RNS is a good idea – but I don’t expect much support for that. (We support it.)
Note that there exists a standard format for an ftp URI which includes username/password. Therefore one could include the information in the JSDL document without any need for delegation. (I do not know gridFTP well, perhaps it supports a similar set of uri options, eliminating the need for passing a delegated credential.)
On the other hand if we choose to support gridFTP, scp, or any other protocol that requires a delegated credential, then we must also agree on a delegation strategy … with a potential need to replace it later. (By the way, we are not familiar with a standard URI format for scp.)
Right now we (the Virginia Genesis II group) support ftp, http, mailto, and RNS with delegated credentials (not via the same mechanism Marty is proposing).
A
------------------------------------------------------------------------
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
Sftp is fine, as is https, the point from my perspective is not to require dealing with the delegation issue yet.
-----Original Message----- From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Vesselin Novov Sent: Thursday, November 01, 2007 2:15 PM To: Marty Humphrey Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] File staging extension
Marty,
Marty Humphrey wrote:
I like a lot of the proposal. But one of the issues here is that none of ftp, http, or mailto is secure. (Note: username/password ftp is still cleartext - not INTO the BES service but rather from the BES service to the FTP service)
Are you concerned with the inclusion of the username/password in the URI string in the JSDL or with the fact that the communication channels is unsecured. Even with the secured sftp we would need to add the username/pass to the sftp: URI string.
-Vesso
-- Marty
*From:* ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] *On Behalf Of *Andrew Grimshaw *Sent:* Thursday, November 01, 2007 1:45 PM *To:* ogsa-hpcp-wg@ogf.org *Subject:* [ogsa-hpcp-wg] File staging extension
All,
Today we discussed which URI's to support in the proposed file staging extensions. Particularly for SC07.
I suggest the following URI's
ftp
http
mailto
because they do not require us to address the issue of delegation in advance of SC07. (As I said at the last OGF I do not think the delegation approach in the delegation proposal is a good idea).
Of course I think ByteIO/RNS is a good idea - but I don't expect much support for that. (We support it.)
Note that there exists a standard format for an ftp URI which includes username/password. Therefore one could include the information in the JSDL document without any need for delegation. (I do not know gridFTP well, perhaps it supports a similar set of uri options, eliminating the need for passing a delegated credential.)
On the other hand if we choose to support gridFTP, scp, or any other protocol that requires a delegated credential, then we must also agree on a delegation strategy . with a potential need to replace it later. (By the way, we are not familiar with a standard URI format for scp.)
Right now we (the Virginia Genesis II group) support ftp, http, mailto, and RNS with delegated credentials (not via the same mechanism Marty is proposing).
A
-----------------------------------------------------------------------
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
Right -- " Are you concerned with the inclusion of the username/password in the URI string in the JSDL?" No. It's over https by definition. A little more broadly, I am concerned that someone could semi-legitimately accuse the HPC Profile effort of "mandating insecurity". -- Marty -----Original Message----- From: Vesselin Novov [mailto:vesso@doc.ic.ac.uk] Sent: Thursday, November 01, 2007 2:15 PM To: Marty Humphrey Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] File staging extension Marty, Marty Humphrey wrote:
I like a lot of the proposal. But one of the issues here is that none of ftp, http, or mailto is secure. (Note: username/password ftp is still cleartext - not INTO the BES service but rather from the BES service to the FTP service)
Are you concerned with the inclusion of the username/password in the URI string in the JSDL or with the fact that the communication channels is unsecured. Even with the secured sftp we would need to add the username/pass to the sftp: URI string. -Vesso
-- Marty
*From:* ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] *On Behalf Of *Andrew Grimshaw *Sent:* Thursday, November 01, 2007 1:45 PM *To:* ogsa-hpcp-wg@ogf.org *Subject:* [ogsa-hpcp-wg] File staging extension
All,
Today we discussed which URI's to support in the proposed file staging extensions. Particularly for SC07.
I suggest the following URI's
ftp
http
mailto
because they do not require us to address the issue of delegation in advance of SC07. (As I said at the last OGF I do not think the delegation approach in the delegation proposal is a good idea).
Of course I think ByteIO/RNS is a good idea - but I don't expect much support for that. (We support it.)
Note that there exists a standard format for an ftp URI which includes username/password. Therefore one could include the information in the JSDL document without any need for delegation. (I do not know gridFTP well, perhaps it supports a similar set of uri options, eliminating the need for passing a delegated credential.)
On the other hand if we choose to support gridFTP, scp, or any other protocol that requires a delegated credential, then we must also agree on a delegation strategy . with a potential need to replace it later. (By the way, we are not familiar with a standard URI format for scp.)
Right now we (the Virginia Genesis II group) support ftp, http, mailto, and RNS with delegated credentials (not via the same mechanism Marty is proposing).
A
------------------------------------------------------------------------
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
Marty Humphrey wrote:
Right -- " Are you concerned with the inclusion of the username/password in the URI string in the JSDL?" No. It's over https by definition.
A little more broadly, I am concerned that someone could semi-legitimately accuse the HPC Profile effort of "mandating insecurity".
Might be worth considering webdav, since that's (almost) http(s) and yet is known to support bidirectional transfers (the semantics of which are messier with http). Longer term, an extension to JSDL to allow the embedding of EPRs would allow for something much more sophisticated, as I think there's something in the WS-Zoo that allows the embedding of credentials (or methods of obtaining them) in EPRs. But not this year. :-) Donal.
A little more broadly, I am concerned that someone could semi-legitimately accuse the HPC Profile effort of "mandating insecurity". We're mandating in HPCBP that over an open network plain text username and passwords are passed over SSL. We're demonstrating a proof of concept that using 'movement protocols' such as ftp, http, ... can be integrated into the HPCBP by passing in a credential from the client. This IMHO is the goal of the normative extensions. The set of credentials that we mandate that we support and the movement protocols that they access is effectively a profile ontop of this normative extensions. If your HPCBP endpoint is only going to go to files within your network (because by policy you do not allow external FTP traffic through your firewall) then use of FTP may not be a major concern. Other deployments going cross-enterprise in their file access may require that certain protocols are only used. Basically I think we have three phases: 1. Proof of concept for SC07 to drive further development of the extensions. 2. Developing normative extensions that are fairly flexible in terms of the things moved and the tokens used to authenticate access to the things being moved. 3. Concrete profiles defining the protocols and the credentials. This set may be very different in different domains, e-science (GridFTP & certificates), commerce (ftp & username/password) for example. 2 & 3 I think this is something we can really discuss post SC07. For now we need to KISS* and together be happy with an answer to 1! Steven KISS = Keep It Simple Stupid (This is a generic working group stupid - not a person specific stupid in this email thread!)
Hi Steven, I'm sorry if I did not make myself clearer. I am NOT suggesting that we remove ftp, for the reasons you mention. Rather, I am stating that the set of 3 does not include something with a reasonable "security story". Sftp and ftps are both "reasonable" in their own ways and arguably should be included in the discussion. On a related topic, how are we going to feel when all of our passwords appear on the "we've-scooped-your-passwords" screen at SC07? :^) -- Marty -----Original Message----- From: Steven Newhouse [mailto:Steven.Newhouse@microsoft.com] Sent: Thursday, November 01, 2007 6:20 PM To: Marty Humphrey; 'Vesselin Novov' Cc: ogsa-hpcp-wg@ogf.org Subject: RE: [ogsa-hpcp-wg] File staging extension A little more broadly, I am concerned that someone could semi-legitimately accuse the HPC Profile effort of "mandating insecurity". We're mandating in HPCBP that over an open network plain text username and passwords are passed over SSL. We're demonstrating a proof of concept that using 'movement protocols' such as ftp, http, ... can be integrated into the HPCBP by passing in a credential from the client. This IMHO is the goal of the normative extensions. The set of credentials that we mandate that we support and the movement protocols that they access is effectively a profile ontop of this normative extensions. If your HPCBP endpoint is only going to go to files within your network (because by policy you do not allow external FTP traffic through your firewall) then use of FTP may not be a major concern. Other deployments going cross-enterprise in their file access may require that certain protocols are only used. Basically I think we have three phases: 1. Proof of concept for SC07 to drive further development of the extensions. 2. Developing normative extensions that are fairly flexible in terms of the things moved and the tokens used to authenticate access to the things being moved. 3. Concrete profiles defining the protocols and the credentials. This set may be very different in different domains, e-science (GridFTP & certificates), commerce (ftp & username/password) for example. 2 & 3 I think this is something we can really discuss post SC07. For now we need to KISS* and together be happy with an answer to 1! Steven KISS = Keep It Simple Stupid (This is a generic working group stupid - not a person specific stupid in this email thread!)
Two small points here, First off, I think we can sell this as a non security problem. We're not proposing ftp as a mechanism for transmitting private data. Especially if we use uernames of "anonymous" and similar passwords. Many people still use ftp for making non-secure information available thus we can do the same here. We use ftp to transfer bioinformatics databases which are also available from a project web page so this can be seen as not a problem. Second, I don't know if anyone saw the spam of the "we've-scooped-your-passwords" last year (if you didn't they got the first five passwords to be the first few lines of the parody on lord of the rings "one OS to rule them all...."). I know the people who did this and it took over 40,000 connections to get these to the top of the list. So hopefully unless we're submitting that many jobs we won't make it that high. Other than that I agree with KISS for now. steve.. Marty Humphrey wrote:
Hi Steven,
I'm sorry if I did not make myself clearer. I am NOT suggesting that we remove ftp, for the reasons you mention. Rather, I am stating that the set of 3 does not include something with a reasonable "security story". Sftp and ftps are both "reasonable" in their own ways and arguably should be included in the discussion.
On a related topic, how are we going to feel when all of our passwords appear on the "we've-scooped-your-passwords" screen at SC07? :^)
-- Marty
-----Original Message----- From: Steven Newhouse [mailto:Steven.Newhouse@microsoft.com] Sent: Thursday, November 01, 2007 6:20 PM To: Marty Humphrey; 'Vesselin Novov' Cc: ogsa-hpcp-wg@ogf.org Subject: RE: [ogsa-hpcp-wg] File staging extension
A little more broadly, I am concerned that someone could semi-legitimately accuse the HPC Profile effort of "mandating insecurity".
We're mandating in HPCBP that over an open network plain text username and passwords are passed over SSL. We're demonstrating a proof of concept that using 'movement protocols' such as ftp, http, ... can be integrated into the HPCBP by passing in a credential from the client. This IMHO is the goal of the normative extensions.
The set of credentials that we mandate that we support and the movement protocols that they access is effectively a profile ontop of this normative extensions. If your HPCBP endpoint is only going to go to files within your network (because by policy you do not allow external FTP traffic through your firewall) then use of FTP may not be a major concern. Other deployments going cross-enterprise in their file access may require that certain protocols are only used.
Basically I think we have three phases: 1. Proof of concept for SC07 to drive further development of the extensions. 2. Developing normative extensions that are fairly flexible in terms of the things moved and the tokens used to authenticate access to the things being moved. 3. Concrete profiles defining the protocols and the credentials. This set may be very different in different domains, e-science (GridFTP & certificates), commerce (ftp & username/password) for example.
2 & 3 I think this is something we can really discuss post SC07. For now we need to KISS* and together be happy with an answer to 1!
Steven
KISS = Keep It Simple Stupid (This is a generic working group stupid - not a person specific stupid in this email thread!)
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
-- ------------------------------------------------------------------------ Dr A. Stephen McGough http://www.doc.ic.ac.uk/~asm ------------------------------------------------------------------------ Technical Coordinator, London e-Science Centre, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8409 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------
The solution proposed by EGEE/OMII for the datastaging with the CREAM-BES is essentially the Andrew's one. We've modified the middleware in order to support "ftp://user:pwd@host" ONLY for this demo; the CREAM-BES usually supports only gsiftp and https. If the service is not able to find these credentials in the URI then it tries to retrieve username&password from WSS header (Username token profile). Having a password written in a jsdl file is abysmal, we know, but for a demo can be a good compromise. For the long term the datastaging is an issue for the OMII project that depends on reaching an agreement for a "common delegation mechanism", so now it's too early for spending more efforts on that. Cheers Paolo A.S.McGough wrote:
Two small points here,
First off, I think we can sell this as a non security problem. We're not proposing ftp as a mechanism for transmitting private data. Especially if we use uernames of "anonymous" and similar passwords. Many people still use ftp for making non-secure information available thus we can do the same here. We use ftp to transfer bioinformatics databases which are also available from a project web page so this can be seen as not a problem.
Second, I don't know if anyone saw the spam of the "we've-scooped-your-passwords" last year (if you didn't they got the first five passwords to be the first few lines of the parody on lord of the rings "one OS to rule them all...."). I know the people who did this and it took over 40,000 connections to get these to the top of the list. So hopefully unless we're submitting that many jobs we won't make it that high.
Other than that I agree with KISS for now.
steve..
Marty Humphrey wrote:
Hi Steven,
I'm sorry if I did not make myself clearer. I am NOT suggesting that we remove ftp, for the reasons you mention. Rather, I am stating that the set of 3 does not include something with a reasonable "security story". Sftp and ftps are both "reasonable" in their own ways and arguably should be included in the discussion.
On a related topic, how are we going to feel when all of our passwords appear on the "we've-scooped-your-passwords" screen at SC07? :^)
-- Marty
-----Original Message----- From: Steven Newhouse [mailto:Steven.Newhouse@microsoft.com] Sent: Thursday, November 01, 2007 6:20 PM To: Marty Humphrey; 'Vesselin Novov' Cc: ogsa-hpcp-wg@ogf.org Subject: RE: [ogsa-hpcp-wg] File staging extension
A little more broadly, I am concerned that someone could semi-legitimately accuse the HPC Profile effort of "mandating insecurity".
We're mandating in HPCBP that over an open network plain text username and passwords are passed over SSL. We're demonstrating a proof of concept that using 'movement protocols' such as ftp, http, ... can be integrated into the HPCBP by passing in a credential from the client. This IMHO is the goal of the normative extensions.
The set of credentials that we mandate that we support and the movement protocols that they access is effectively a profile ontop of this normative extensions. If your HPCBP endpoint is only going to go to files within your network (because by policy you do not allow external FTP traffic through your firewall) then use of FTP may not be a major concern. Other deployments going cross-enterprise in their file access may require that certain protocols are only used.
Basically I think we have three phases: 1. Proof of concept for SC07 to drive further development of the extensions. 2. Developing normative extensions that are fairly flexible in terms of the things moved and the tokens used to authenticate access to the things being moved. 3. Concrete profiles defining the protocols and the credentials. This set may be very different in different domains, e-science (GridFTP & certificates), commerce (ftp & username/password) for example.
2 & 3 I think this is something we can really discuss post SC07. For now we need to KISS* and together be happy with an answer to 1!
Steven
KISS = Keep It Simple Stupid (This is a generic working group stupid - not a person specific stupid in this email thread!)
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
Late the the game for a response, but oh well... I'm basically in agreement with Steven. The point of the interop is to show the possibility, not to demonstrate production data movement. For those who really want secure transfer, the low hanging fruit for encrypted communications is scp/sftp IMHO. -- Chris On 01/11/07 15:19, "Steven Newhouse" <Steven.Newhouse@microsoft.com> wrote:
A little more broadly, I am concerned that someone could semi-legitimately accuse the HPC Profile effort of "mandating insecurity".
We're mandating in HPCBP that over an open network plain text username and passwords are passed over SSL. We're demonstrating a proof of concept that using 'movement protocols' such as ftp, http, ... can be integrated into the HPCBP by passing in a credential from the client. This IMHO is the goal of the normative extensions.
The set of credentials that we mandate that we support and the movement protocols that they access is effectively a profile ontop of this normative extensions. If your HPCBP endpoint is only going to go to files within your network (because by policy you do not allow external FTP traffic through your firewall) then use of FTP may not be a major concern. Other deployments going cross-enterprise in their file access may require that certain protocols are only used.
Basically I think we have three phases: 1. Proof of concept for SC07 to drive further development of the extensions. 2. Developing normative extensions that are fairly flexible in terms of the things moved and the tokens used to authenticate access to the things being moved. 3. Concrete profiles defining the protocols and the credentials. This set may be very different in different domains, e-science (GridFTP & certificates), commerce (ftp & username/password) for example.
2 & 3 I think this is something we can really discuss post SC07. For now we need to KISS* and together be happy with an answer to 1!
Steven
KISS = Keep It Simple Stupid (This is a generic working group stupid - not a person specific stupid in this email thread!)
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
participants (8)
-
A.S.McGough -
Andrew Grimshaw -
Christopher Smith -
Donal K. Fellows -
Marty Humphrey -
Paolo Andretto -
Steven Newhouse -
Vesselin Novov