Teleconference minutes - 22 June 2006
Attached. Main topics: - BSP public comment review - Information modeling discussion Gridforge: https://forge.gridforum.org/sf/go/doc13624?nav=1 -- Andreas Savva OGSA Teleconference - 22 June 2006 ================================== * Participants Michel Drescher (Fujitsu) Hiro Kishimoto (Fujitsu) Takuya Mori (NEC) Darren Pulsipher (EMC) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Marvin Theimer (Microsoft) Jem Treadwell (HP) Pete Ziu (Northrop Grumman) Minutes: Andreas Savva * June 12 minutes approved with no changes * June 15 minutes approved with no changes * Action items review - Andreas will categorize OGSA 1.5 issues and send the list to Dave Snelling. - Done, waiting for response. - Review at next "OGSA 1.5" call. - Andreas and Hiro to talk offline about how to start sending ical invitations. - Done. - Andreas will send an email to the list explaining where the calendar is and what invitations will be sent out. - Jun will correct the CDL XML examples written by Hiro. - No update. - Hiro will probably move the review teleconference to another day. - EMS team (Steven, Andreas, Donal) to review data staging scenario (section 5 of https://forge.gridforum.org/sf/go/doc13591?nav=1 ) (postpone until June 22) - Andreas has read it. - Bring to people's attention again at the next EMS call. - Add sequence diagrams to the scenarios: (postpone until June 22) -- Andreas will do the "Install application" scenario (3.1) -- Mike will do the "Install application using ACS" scenario (3.3) -- Other volunteers welcome. (Andreas will ask Donal for the EPS scenario) - Andreas has started doing the sequence diagrams in RSM - Darren volunteered to help out - Review again at the next EMS call - Andreas will merge draft scenarios and sequence diagrams to the "EMS Architecture Scenarios" document (postpone until June 22) - Review again at the next EMS call. * Roadmap (postponed) * Authorization (postponed) * BSP Public Comments Reviewed public comments and Takuya's proposed replies 1. Add text explaining that the Secure Channel profile is not required by all ogsa services. The introduction is probably a good place for this. 2. [Basic-Security-Profile] usage. The term is defined in the document. Takuya to check whether such special terms are used consistently and that they stand out. Refer to the WSRF BP for a similar example. 3. Ciphersuites: Agreed that it important to list acceptable ciphers. - As a first step Takuya will list up available ones (from the WS-I BSP); select the ones that are in common use; and then select the ones that are considered sufficiently safe. - Review the list at the next BSP teleconf 4. Multiple keys in keyinfo field? - Takuya to talk to Von in order to understand the use case for multiple keys; and will propose a resolution at the next BSP teleconf. The next BSP review is set for the June 29 teleconference. * Information Model rendering discussion Started with the question of whether a rendering discussion is the right discussion to have. Concluded that talking only about the rendering overlooks more important issues: what the intermediate model should be and how it should be derived. One question is whether it is possible to define tags with semantics sufficiently pinned down to offer users the guarantee that a correct choice will be made when placing a job. For example, what does the system guarantee the user when a job requesting a box with "OS=Linux" (possibly of a specific version). There is enough variance to match with a box that advertises itself in this way but will not be able to run the job for other reasons (configuration etc). And vice versa other boxes that could potentially run the job may be missed. There was some discussion on various lists (BES, JSDL) already about the feasibility of defining equivalence classes but it is unlikely that anything like that can be done in the near term. The best that can be done is to define such terms while leaving some of the details unsaid (in the manner of JSDL). There is a tension between trying to describe something precisely while allowing the necessary looseness. Another issue is how to define the set of terms that people will actually want to use. There are many successful systems that are based mainly on user defined tags (or, equivalently, pre-configured queues that guarantee some kind of resource configuration) that are mainly site specific. It may not be possible to define these tags normatively however. So one key decision for the intermediate model is whether it should be driven by site-specific/defined information; or whether it should be driven from precise definitions like CIM. - There has been success for both sides (noting that Condor successes are often linked to also providing concrete specifications) - Informal definitions might not work across sites and this is a big issue for interoperability. - One community driven way forward would be to set up a framework to define combinations of capabilities; but this is likely to take a long time. GGF has published work with JSDL 1.0. The model is known to have deficiencies but captures a small set of common resource descriptions. The terms & concepts are a distillation of terms already in use at a number of sites running Globus, Unicore, (and to some extent Condor). - There is a compliance issue. For example, what does it really mean to say that a system is JSDL 1.0 compliant? What should the users expectation be and can the vendor deliver accordingly? - CIM has some experience in this area. It precisely enumerates known features (but there is no notion of (algorithmic) equivalence classes). Tentative consensus that both approaches are needed. It is important to be careful not to promise more than can be done with JSDL style resource descriptions. And that keeping these fuzzy to some extent does that. Also that user defined tags are needed. Since JSDL already allows the inclusion of user defined tags (xsd:any) the next question is whether there is a need to also define a framework for users to define their tags or to leave this completely open. Tentative consensus that defining a (or some) generic element with associated well defined matching semantics to allow users to add their own tags is a good idea. Marvin is working on a proposal for such an element and will post it to the relevant list(s). - Jay is also probably thinking along these lines so some offline discussion between Jay and Marvin might be good. - The proposal should be sent mainly to the OGSA Information Modeling team since they are the drivers of this work. And also to JSDL and BES; the other stakeholders in this process.
Hi All, As part of the OGSA Basic Security Profile (OGSA-BSP) discussion, I am sending a note to describe general guidelines for selecting ciphersuites with a list of proposed ciphersuites which are allowed to be used for a TLS/SSL connection and the available ciphersuites defined in the TLS and SSL specification. The note is intended to be used for a discussion for selecting acceptable ciphersuites (or discouraged ciphersuites). Because the WS-I BSP has already selected RECOMMENDED ciphersuites, it is not needed to select our own RECOMMENDED ciphersuites additionally(,IMO). My proposal for the revision of the OGSA-BSP Secure Channel is - to add general guidelines for selecting ciphersuites described in the note as restrictions - to list discouraged ciphersuites from the TLS and SSL specifications in the Appendix. Any comments are welcomed, Takuya 8<------------- cut here ---------------------------------------- Sep. 05 Takuya Mori "note: ciphersuites selection" * general guidelines for ciphersuite selection - a ciphersuite with NULL cipher algorithm SHOULD not be used because it provides no confidentiality - a key exchange algorithm with 'anon' SHOULD not be used because it provides no authentication - a cipher algorithm with key length less than 64 bits SHOULD not be used because it is known to be insecure (it includes DES algorithm and RC4 algorithm with 40 bits key) - MD5 hash algorithm SHOULD not be used because it is know to be insecure * proposed ciphersuites which are allowed to be used The following is the list of the ciphersuites from the TLS and SSL specifications which are allowed to be used. All the other ciphersuites available in the TLS and SSL specification are discouraged to be used. TLS_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_IDEA_CBC_SHA SSL_RSA_WITH_IDEA_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA Note: The name of a ciphersuites represents the cipher mecanisms - a Protocol Name (TLS or SSL) followed by - a Key Exchange Algorithm followed by - _WITH_ or _EXPORT_WITH_ - an Cipher Algorithm followed by - a Hash Algorithm * available ciphersuites from TLS and SSL specifications. Note: The marks in the beginning of each line mean: R: Recommended IS: InSecure algorithm or key length NE: No Encryption NA: No Authentication (Anonymous communication) ** ciphersuites defined in the TLS specification (note: all the cipherstuites are identical with the counterparts in SSL but have different names) ---- NE TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; NE TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; IS TLS_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; IS TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; R TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; IS TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; R TLS_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; IS TLS_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; IS TLS_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; R TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; IS TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; IS TLS_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; R TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; IS TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; IS TLS_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; R TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; IS TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; IS TLS_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; R TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; IS TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; IS TLS_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; R TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; NAIS TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; NA TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; NAIS TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; NAIS TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; NA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; ---- o ciphersuites defined in the SSL specification. (note: the first 27 cipherstuites are identical with the counterparts in TLS but have different names) (note: SSL_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA is not recommended because it is not widely used other than the U.S. Government and their Military.) ---- NE SSL_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; NE SSL_RSA_WITH_NULL_SHA = { 0x00,0x02 }; IS SSL_RSA_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x03 }; IS SSL_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; R SSL_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; IS SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x06 }; R SSL_RSA_WITH_IDEA_CBC_SHA = { 0x00,0x07 }; IS SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x08 }; IS SSL_RSA_WITH_DES_CBC_SHA = { 0x00,0x09 }; R SSL_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; IS SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0B }; IS SSL_DH_DSS_WITH_DES_CBC_SHA = { 0x00,0x0C }; R SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; IS SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x0E }; IS SSL_DH_RSA_WITH_DES_CBC_SHA = { 0x00,0x0F }; R SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; IS SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x11 }; IS SSL_DHE_DSS_WITH_DES_CBC_SHA = { 0x00,0x12 }; R SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; IS SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x14 }; IS SSL_DHE_RSA_WITH_DES_CBC_SHA = { 0x00,0x15 }; R SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; NAIS SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x17 }; NA SSL_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; NAIS SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA = { 0x00,0x19 }; NAIS SSL_DH_anon_WITH_DES_CBC_SHA = { 0x00,0x1A }; NAIS SSL_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; NE SSL_FORTEZZA_DMS_WITH_NULL_SHA = { 0X00,0X1C }; SSL_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA = { 0x00,0x1D }; ---- * RECOMMENDED ciphersuites defined in the WS-I BSP. The following is the RECOMMENDED ciphersuites: for TLS-capable implementations - TLS_RSA_WITH_AES_128_CBC_SHA or TLS_RSA_FIPS_WITH_AES_128_CBC_SHA for SSL-capable implementations - SSL_RSA_WITH_AES_128_CBC_SHA or SSL_RSA_FIPS_WITH_AES_128_CBC_SHA (Actually, these ciphersuites are not from the TLS or SSL specifications but from other specifications including RFC-3268, "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)".) EOT 8<------------- cut here ---------------------------------------- ---- Takuya Mori moritaku@bx.jp.nec.com / tk-mori@isd.nec.co.jp System Platform Software Development Division NEC Corporation, Tokyo Japan
participants (2)
-
Andreas Savva -
Takuya Mori