FW: [Fwd: FIle Staging Extensions Comment]
-----Original Message----- From: Mark Morgan [mailto:mmm2a@virginia.edu] Sent: Monday, June 23, 2008 6:40 PM To: humphrey@cs.virginia.edu; Steven Newhouse; csmith@platform.com; Richard Ciapala Subject: [Fwd: FIle Staging Extensions Comment]
I wasn't able to post this to the HPCP mailing list.
From: ogsa-hpcp-wg-owner@ogf.org To: mmm2a@virginia.edu Subject: FIle Staging Extensions Comment Date: Mon, 23 Jun 2008 12:38:31 -0500
You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at ogsa-hpcp-wg-owner@ogf.org.
email message attachment
-------- Forwarded Message -------- From: Mark Morgan <mmm2a@virginia.edu> To: ogsa-hpcp-wg@ogf.org Subject: FIle Staging Extensions Comment Date: Mon, 23 Jun 2008 13:36:30 -0400
I recently went to implement some of the file staging extensions
the HPC group has described. In particular I was looking to implement SCP and I figured that if I was going to implement that spec., it made sense to do it according to a standard rather than to come up with something new and non-interoperable. However, in the process of implementing the specification, I came across a minor nitpick that I have concerns about. Specifically, if I read the specification correctly, I believe that it is the case that a BES container is required by the spec. to fault if a user passes authentication information in the URI rather than using the file staging extensions. I'm confused as to why the group decided to prohibit a valid form of extension to the JSDL and BES specification. I understand that
method of passing information may not be the best choice or most secure choice, but I would think that it makes more sense for the HPC group to simply standardize on their way of passing authentication information rather than prohibit other, in my opinion, equally valid authentication mechanisms. The fact of the matter is that Genesis II has, in the
-------- Forwarded Message -------- that that past,
allowed authentication information to be passed in the File staging URIs. At this point, it seems like I have the choice of forgoing backwards compatibility in favor of HPCP File staging extensions compliance, or forgoing HPCP File staging compliance in favor of backward compatibility where I really see no good reason why both couldn't be achieved.
I'm not trying to cause trouble here, I'm simply curious as to the reasons for this decision and specifically wanted to mention this in case the HPC group hadn't thought of this potential issue before.
-Mark
I recently went to implement some of the file staging extensions that the HPC group has described. In particular I was looking to implement SCP and I figured that if I was going to implement that spec., it made sense to do it according to a standard rather than to come up with something new and non-interoperable. However, in the process of implementing the specification, I came across a minor nitpick that I have concerns about. Specifically, if I read the specification correctly, I believe that it is the case that a BES container is required by the spec. to fault if a user passes authentication information in the URI rather than using the file staging extensions. I'm confused as to why the group decided to prohibit a valid form of extension to the JSDL and BES specification. I understand that that method of passing information may not be the best choice or most secure choice, but I would think that it makes more sense for the HPC group to simply standardize on their way of passing authentication information rather than prohibit other, in my opinion, equally valid authentication mechanisms. The fact of the matter is that Genesis II has, in the past, allowed authentication information to be passed in the File staging URIs. At this point, it seems like I have the choice of forgoing backwards compatibility in favor of HPCP File staging extensions compliance, or forgoing HPCP File staging compliance in favor of backward compatibility where I really see no good reason why both couldn't be achieved.
I'm not trying to cause trouble here, I'm simply curious as to the reasons for this decision and specifically wanted to mention this in case the HPC group hadn't thought of this potential issue before.
It was discussed in the working group. My recollection was that there was no defined 'standard' mechanism for embedding a username and password into an scp uri. Therefore we did not feel happy specifying one. Steven
Steven Newhouse wrote:
It was discussed in the working group. My recollection was that there was no defined 'standard' mechanism for embedding a username and password into an scp uri. Therefore we did not feel happy specifying one.
I'd have thought in that case that going with the "generic URI" format for usernames and passwords would be the right thing then, leading to: scp://user:pass@host.com/path/to/file This will be pretty easy to implement (stripping the password out and passing it to the copier correctly won't be a big challenge). However, reading http://tools.ietf.org/html/rfc3986 (the current definition of the generic URI format) leads to a problem with this, in that the embedding of passwords here is massively unsafe and leads to a range of troubles (including, but not limited to, making the document highly security-sensitive). I think we already knew that! (On the plus side, I don't think we need to worry so much about the issues documented in section 7.6 of that RFC for now; JSDL isn't a user-focussed format...) What we really need here is proper security delegation. That's the only solution which is actually of any real long-term good. This is just a (necessary) band-aid. Donal.
Donal K. Fellows wrote:
Steven Newhouse wrote:
It was discussed in the working group. My recollection was that there was no defined 'standard' mechanism for embedding a username and password into an scp uri. Therefore we did not feel happy specifying one.
I'd have thought in that case that going with the "generic URI" format for usernames and passwords would be the right thing then, leading to:
scp://user:pass@host.com/path/to/file
This is basically the format described in: http://tools.ietf.org/html/draft-ietf-secsh-scp-sftp-ssh-uri-01 (minus many complicated bits). Though that never progressed beyond draft, it's probably as good a point to start from as anywhere. Donal.
Which is why we decided not to support the credential embedded in the URI and to put in an extensible Credential element placed in the JSDL document for each stage in/out element. Steven
-----Original Message----- From: Donal K. Fellows [mailto:donal.k.fellows@manchester.ac.uk] Sent: Sunday, June 29, 2008 4:38 PM To: Steven Newhouse Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]
Steven Newhouse wrote:
It was discussed in the working group. My recollection was that there was no defined 'standard' mechanism for embedding a username and password into an scp uri. Therefore we did not feel happy specifying one.
I'd have thought in that case that going with the "generic URI" format for usernames and passwords would be the right thing then, leading to:
scp://user:pass@host.com/path/to/file
This will be pretty easy to implement (stripping the password out and passing it to the copier correctly won't be a big challenge). However, reading http://tools.ietf.org/html/rfc3986 (the current definition of the generic URI format) leads to a problem with this, in that the embedding of passwords here is massively unsafe and leads to a range of troubles (including, but not limited to, making the document highly security-sensitive). I think we already knew that! (On the plus side, I don't think we need to worry so much about the issues documented in section 7.6 of that RFC for now; JSDL isn't a user-focussed format...)
What we really need here is proper security delegation. That's the only solution which is actually of any real long-term good. This is just a (necessary) band-aid.
Donal.
Well, just to be clear on my purpose in mailing the group, it wasn't to ask the group to put username/password into the URI or to specify a format for putting it into the URI. My concern was that the HPCP specification explicitly prohibits an HPCP File Extension compliant endpoint from accepting the username/password in the URI. While I agree in principle that username/password in the URI is unsafe, I don't think that the HPCP Profile should restrict or limit another valid implementation from using it that way. Can't the HPCP simply specify what the File Extensions add as specification and remain silent on other ways of doing it? -Mark On Sun, 2008-06-29 at 22:53 -0700, Steven Newhouse wrote:
Which is why we decided not to support the credential embedded in the URI and to put in an extensible Credential element placed in the JSDL document for each stage in/out element.
Steven
-----Original Message----- From: Donal K. Fellows [mailto:donal.k.fellows@manchester.ac.uk] Sent: Sunday, June 29, 2008 4:38 PM To: Steven Newhouse Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]
Steven Newhouse wrote:
It was discussed in the working group. My recollection was that there was no defined 'standard' mechanism for embedding a username and password into an scp uri. Therefore we did not feel happy specifying one.
I'd have thought in that case that going with the "generic URI" format for usernames and passwords would be the right thing then, leading to:
scp://user:pass@host.com/path/to/file
This will be pretty easy to implement (stripping the password out and passing it to the copier correctly won't be a big challenge). However, reading http://tools.ietf.org/html/rfc3986 (the current definition of the generic URI format) leads to a problem with this, in that the embedding of passwords here is massively unsafe and leads to a range of troubles (including, but not limited to, making the document highly security-sensitive). I think we already knew that! (On the plus side, I don't think we need to worry so much about the issues documented in section 7.6 of that RFC for now; JSDL isn't a user-focussed format...)
What we really need here is proper security delegation. That's the only solution which is actually of any real long-term good. This is just a (necessary) band-aid.
Donal.
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
I believe one of the motivating factors for leaving it out was to deal with the ambiguity of having embedded username/password in potential conflict with the "Credential" element. We decided to say that if you want to pass username and password, do it in the Credential element. Otherwise you get in a situation where the implementation doesn't know which username/password to use. Simplify in order to aid interoperability was the guiding principal. I, for one, stick with the original reasoning and think restricting the URI is a good idea. -- Chris On 30/6/08 06:20, "Mark Morgan" <mmm2a@virginia.edu> wrote:
Well, just to be clear on my purpose in mailing the group, it wasn't to ask the group to put username/password into the URI or to specify a format for putting it into the URI. My concern was that the HPCP specification explicitly prohibits an HPCP File Extension compliant endpoint from accepting the username/password in the URI. While I agree in principle that username/password in the URI is unsafe, I don't think that the HPCP Profile should restrict or limit another valid implementation from using it that way. Can't the HPCP simply specify what the File Extensions add as specification and remain silent on other ways of doing it?
-Mark
On Sun, 2008-06-29 at 22:53 -0700, Steven Newhouse wrote:
Which is why we decided not to support the credential embedded in the URI and to put in an extensible Credential element placed in the JSDL document for each stage in/out element.
Steven
-----Original Message----- From: Donal K. Fellows [mailto:donal.k.fellows@manchester.ac.uk] Sent: Sunday, June 29, 2008 4:38 PM To: Steven Newhouse Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]
Steven Newhouse wrote:
It was discussed in the working group. My recollection was that there was no defined 'standard' mechanism for embedding a username and password into an scp uri. Therefore we did not feel happy specifying one.
I'd have thought in that case that going with the "generic URI" format for usernames and passwords would be the right thing then, leading to:
scp://user:pass@host.com/path/to/file
This will be pretty easy to implement (stripping the password out and passing it to the copier correctly won't be a big challenge). However, reading http://tools.ietf.org/html/rfc3986 (the current definition of the generic URI format) leads to a problem with this, in that the embedding of passwords here is massively unsafe and leads to a range of troubles (including, but not limited to, making the document highly security-sensitive). I think we already knew that! (On the plus side, I don't think we need to worry so much about the issues documented in section 7.6 of that RFC for now; JSDL isn't a user-focussed format...)
What we really need here is proper security delegation. That's the only solution which is actually of any real long-term good. This is just a (necessary) band-aid.
Donal.
-- 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
I agree with this -- again, we didn't want the compliant implementation to need to support TWO options here, and in addition be faced with the confusion regarding a message that contains BOTH. So we think restricting the URI is a good thing. -----Original Message----- From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] On Behalf Of Christopher Smith Sent: Monday, June 30, 2008 11:08 AM To: Mark Morgan; Steven Newhouse Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment] I believe one of the motivating factors for leaving it out was to deal with the ambiguity of having embedded username/password in potential conflict with the "Credential" element. We decided to say that if you want to pass username and password, do it in the Credential element. Otherwise you get in a situation where the implementation doesn't know which username/password to use. Simplify in order to aid interoperability was the guiding principal. I, for one, stick with the original reasoning and think restricting the URI is a good idea. -- Chris On 30/6/08 06:20, "Mark Morgan" <mmm2a@virginia.edu> wrote:
Well, just to be clear on my purpose in mailing the group, it wasn't to ask the group to put username/password into the URI or to specify a format for putting it into the URI. My concern was that the HPCP specification explicitly prohibits an HPCP File Extension compliant endpoint from accepting the username/password in the URI. While I agree in principle that username/password in the URI is unsafe, I don't think that the HPCP Profile should restrict or limit another valid implementation from using it that way. Can't the HPCP simply specify what the File Extensions add as specification and remain silent on other ways of doing it?
-Mark
On Sun, 2008-06-29 at 22:53 -0700, Steven Newhouse wrote:
Which is why we decided not to support the credential embedded in the URI and to put in an extensible Credential element placed in the JSDL document for each stage in/out element.
Steven
-----Original Message----- From: Donal K. Fellows [mailto:donal.k.fellows@manchester.ac.uk] Sent: Sunday, June 29, 2008 4:38 PM To: Steven Newhouse Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]
Steven Newhouse wrote:
It was discussed in the working group. My recollection was that there was no defined 'standard' mechanism for embedding a username and password into an scp uri. Therefore we did not feel happy specifying one.
I'd have thought in that case that going with the "generic URI" format for usernames and passwords would be the right thing then, leading to:
scp://user:pass@host.com/path/to/file
This will be pretty easy to implement (stripping the password out and passing it to the copier correctly won't be a big challenge). However, reading http://tools.ietf.org/html/rfc3986 (the current definition of the generic URI format) leads to a problem with this, in that the embedding of passwords here is massively unsafe and leads to a range of troubles (including, but not limited to, making the document highly security-sensitive). I think we already knew that! (On the plus side, I don't think we need to worry so much about the issues documented in section 7.6 of that RFC for now; JSDL isn't a user-focussed format...)
What we really need here is proper security delegation. That's the only solution which is actually of any real long-term good. This is just a (necessary) band-aid.
Donal.
-- 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
-- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg
I'm also in agreement with this position. The recommendation for interop purposes is to put username/password in the Credential element. The HPCP specs should not encourage or support other mechanisms as compliant options. /Blair
-----Original Message----- From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg- bounces@ogf.org] On Behalf Of Marty Humphrey Sent: Thursday, July 03, 2008 6:24 AM To: 'Christopher Smith'; 'Mark Morgan'; Steven Newhouse Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]
I agree with this -- again, we didn't want the compliant implementation to need to support TWO options here, and in addition be faced with the confusion regarding a message that contains BOTH. So we think restricting the URI is a good thing.
-----Original Message----- From: ogsa-hpcp-wg-bounces@ogf.org [mailto:ogsa-hpcp-wg- bounces@ogf.org] On Behalf Of Christopher Smith Sent: Monday, June 30, 2008 11:08 AM To: Mark Morgan; Steven Newhouse Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]
I believe one of the motivating factors for leaving it out was to deal with the ambiguity of having embedded username/password in potential conflict with the "Credential" element. We decided to say that if you want to pass username and password, do it in the Credential element. Otherwise you get in a situation where the implementation doesn't know which username/password to use.
Simplify in order to aid interoperability was the guiding principal. I, for one, stick with the original reasoning and think restricting the URI is a good idea.
-- Chris
On 30/6/08 06:20, "Mark Morgan" <mmm2a@virginia.edu> wrote:
Well, just to be clear on my purpose in mailing the group, it wasn't to ask the group to put username/password into the URI or to specify a format for putting it into the URI. My concern was that the HPCP specification explicitly prohibits an HPCP File Extension compliant endpoint from accepting the username/password in the URI. While I agree in principle that username/password in the URI is unsafe, I don't think that the HPCP Profile should restrict or limit another valid implementation from using it that way. Can't the HPCP simply specify what the File Extensions add as specification and remain silent on other ways of doing it?
-Mark
Which is why we decided not to support the credential embedded in
to put in an extensible Credential element placed in the JSDL document for each stage in/out element.
Steven
-----Original Message----- From: Donal K. Fellows [mailto:donal.k.fellows@manchester.ac.uk] Sent: Sunday, June 29, 2008 4:38 PM To: Steven Newhouse Cc: ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-hpcp-wg] [Fwd: FIle Staging Extensions Comment]
Steven Newhouse wrote:
It was discussed in the working group. My recollection was that
was no defined 'standard' mechanism for embedding a username and password into an scp uri. Therefore we did not feel happy specifying one.
I'd have thought in that case that going with the "generic URI"
for usernames and passwords would be the right thing then, leading to:
scp://user:pass@host.com/path/to/file
This will be pretty easy to implement (stripping the password out and passing it to the copier correctly won't be a big challenge). However, reading http://tools.ietf.org/html/rfc3986 (the current definition of the generic URI format) leads to a problem with this, in that the embedding of passwords here is massively unsafe and leads to a range of troubles (including, but not limited to, making the document highly security-sensitive). I think we already knew that! (On the plus side, I don't think we need to worry so much about the issues documented in section 7.6 of that RFC for now; JSDL isn't a user-focussed
On Sun, 2008-06-29 at 22:53 -0700, Steven Newhouse wrote: the URI and there format format...)
What we really need here is proper security delegation. That's the
only
solution which is actually of any real long-term good. This is just a (necessary) band-aid.
Donal.
-- 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
-- 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
participants (6)
-
Blair Dillaway -
Christopher Smith -
Donal K. Fellows -
Mark Morgan -
Marty Humphrey -
Steven Newhouse