Teleconference minutes - 12 September 2005
Minutes attached. * Jan 2006 F2F update * Roadmap 1.0 review * Secure Channel 1.0 review Griforge URL: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050912/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 12 September 2005 ======================================= * Participants Jem Treadwell (HP) Andreas Savva (Fujitsu) Steven Newhouse (OMII) Takuya Mori (NEC) Tom Maguire (EMC) Hiro Kishimoto (Fujitsu) Mike Behrens (R2AD, LLC) Minutes: Andreas Savva * Sep 7 minutes approved with no changes * Jan 2006 F2F update Hiro has reserved a room at the FLA Sunnyvale facility for the week of Jan 16. (Same place used for the August meeting.) * Roadmap 1.0 review Review of draft 21. - The change in Introduction, first paragraph, should be propagated to the Abstract too. - "Use of SAML for OGSI Authorization version 1.0" - Since this is for OGSI it should be dropped from the Roadmap. - Version 2.0 of this document might be based on WSRF but there is no concrete decision by the AuthZ WG yet. (Rechartering discussion still going on.) So such an entry cannot be added now. - Agreed to drop and update Roadmap accordingly (incl. spreadsheet). - "Attributes used in OGSA Authorization" - In its current form it is not a Profile and so should be moved to section 4. - Roadmap title - The title should be changed so as to use OGSA as an adjective - It would also be nice to have OGSA(tm) in the title. - A number of alternatives were proposed and rejected before consensus was reached on "Defining the Grid: A Roadmap for OGSA(tm) Standards version 1.0" - Sec.2.3: The OGSA-Related Naming Guidelines draft was recently made public by the GGF Editor. Section 2.3 should be updated accordingly and include a reference to this note. - Sec.5.3.3. contents should be made similar to 5.2.3 since they are both about the 'same' kind of Profiles. - What are the criteria for including a profile in section 5? - Agreed to add a sentence that Profiles must be based on the OGSA Profile Definition document. - All editing actions to be done by Jem. - Issue final call on the next draft. * Secure Channel 1.0 review Reviewed draft sent out by Takuya. https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-securit... - Title: It is different from the title given for this document in the Roadmap document. Agreed to change the title of this draft. - Status: Based on the contents of the Status section of the WSRF BP. Agreed to revise to make more specific to this Profile. - Abstract: Agreed to rewrite to focus on security aspects covered by this Profile. - Introduction: Agreed to rewrite to focus on security aspects of this Profile. - Profile Overview: Agreed to rewrite to focus on security aspects of this Profile. - Relationship with other profiles: Add relationship to WSRF BP and Anonymous Channel Profiles. - Targets: Reduce to the ones used in the document directly (and not just due to cross-referencing from terms in this section) - Conformance claim: Add the general basic security conformance claim URI defined by WSRF BP 1.0. - Sec.3 Security: Break into sections for each referenced profile (BSP and SAML) per WSRF BP. - Use of SSL: Takuya's intention with R0305 is to restrict use of SSL 3.0 ("MUST use TLS") - Agreed to revise R0305 for clarity. - R0301,0302: mandates that the RECEIVER support both TLS and MLS; and SENDER can use either. - Hiro thinks that this sets too high a bar on implementations and should be relaxed for the RECEIVER also. - Takuya thinks that the secure channel profile sets a high bar anyway so this additional requirement is acceptable and is needed to promote interoperability. - No consensus reached. - Takuya will put the issue to the list to get more opinions. * Next call - Secure Channel Profile review to be scheduled for the Monday call.
Hi All, I am sending this message to get more opinions on the issue about requiring the implementations to support both TLS and MLS. Hopefully, I'd like to form a consensus on it before reviewing the BSP on the next monday call.
- R0301,0302: mandates that the RECEIVER support both TLS and MLS; and SENDER can use either. - Hiro thinks that this sets too high a bar on implementations and should be relaxed for the RECEIVER also. - Takuya thinks that the secure channel profile sets a high bar anyway so this additional requirement is acceptable and is needed to promote interoperability. - No consensus reached. - Takuya will put the issue to the list to get more opinions.
Here is the statement. ---- R0301 A RECEIVER MUST support both Transport Layer Security and Message Level Security as profiled in the section 3.2 and 3.3 of this Profile. R0302 A SENDER MUST employ, at least, one of Transport Layer Security or Message Level Security as profiled in the section 3.2 and 3.3 of this Profile. ---- The current draft of the OGSA BSP10 Secure Channel mandates a RECEIVER to "support" both TLS and MLS, while it requires to use at least one of them for a SENDER. My intention here is that to require the support of the both of TLS and MLS by a RECEIVER is essential to ensure interoperability, because supporting one of them by a RECEIVER allows mismatch of the protocol between a RECEIVER and SENDER. On the otherhand, as described in the minutes above by Andreas, Hiro thinks that this sets too high a bar on implementations and should be relaxed for the RECEIVER also. I can also understand his opinion. And I think the cause of the contrary is that we have different priorities between interoperability and practicability. Any comments to this issue will be welcomed very much! Just telling us your preference will also be great. Thanks, Takuya
Thanks Takuya for starting this discussion thread. Yes, I think R0301 sets bar too high, IMHO. I would make one more point that R0302 cannot allow client-side simpler implementation. Given that OGSA WSRF BP 1.0 mandates to provide state-change notification, client-side implementation is RECEIVER of such state-change notifications. Thus both server-side and client-side software must support TLS and MLS. I guess that is not Takuya's intention. Thoughts? ---- Hiro Kishimoto Takuya Mori wrote:
Hi All,
I am sending this message to get more opinions on the issue about requiring the implementations to support both TLS and MLS.
Hopefully, I'd like to form a consensus on it before reviewing the BSP on the next monday call.
- R0301,0302: mandates that the RECEIVER support both TLS and MLS; and SENDER can use either. - Hiro thinks that this sets too high a bar on implementations and should be relaxed for the RECEIVER also. - Takuya thinks that the secure channel profile sets a high bar anyway so this additional requirement is acceptable and is needed to promote interoperability. - No consensus reached. - Takuya will put the issue to the list to get more opinions.
Here is the statement.
---- R0301 A RECEIVER MUST support both Transport Layer Security and Message Level Security as profiled in the section 3.2 and 3.3 of this Profile.
R0302 A SENDER MUST employ, at least, one of Transport Layer Security or Message Level Security as profiled in the section 3.2 and 3.3 of this Profile. ----
The current draft of the OGSA BSP10 Secure Channel mandates a RECEIVER to "support" both TLS and MLS, while it requires to use at least one of them for a SENDER.
My intention here is that to require the support of the both of TLS and MLS by a RECEIVER is essential to ensure interoperability, because supporting one of them by a RECEIVER allows mismatch of the protocol between a RECEIVER and SENDER.
On the otherhand, as described in the minutes above by Andreas, Hiro thinks that this sets too high a bar on implementations and should be relaxed for the RECEIVER also.
I can also understand his opinion. And I think the cause of the contrary is that we have different priorities between interoperability and practicability.
Any comments to this issue will be welcomed very much! Just telling us your preference will also be great.
Thanks, Takuya
Hi all,
- Secure Channel Profile review to be scheduled for the Monday call.
I've uploaded the following two documents. - OGSA Basic Security Profile 1.0 - Secure Channel v004 https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-s... - OGSA Basic Security Profile 1.0 - Anonymous Channel v001 https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Basic_Security_Pr... I'd like these documents to be reviewed in the Monday call. Thank you, Takuya
I've changed the access type and administrative title of the anonymous channel document. The new URL for the anonymous channel document is, https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-s... and it should have public access. (no changes to the document itself, right now) Thanks, Takuya From: Takuya Mori <moritaku@bx.jp.nec.com> Subject: Re: [ogsa-wg] Teleconference minutes - 12 September 2005 Date: Mon, 19 Sep 2005 08:28:30 +0900 (JST)
Hi all,
- Secure Channel Profile review to be scheduled for the Monday call.
I've uploaded the following two documents.
- OGSA Basic Security Profile 1.0 - Secure Channel v004 https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-s...
- OGSA Basic Security Profile 1.0 - Anonymous Channel v001 https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Basic_Security_Pr...
I'd like these documents to be reviewed in the Monday call.
Thank you, Takuya
participants (3)
-
Andreas Savva -
Hiro Kishimoto -
Takuya Mori