Marty, I appreciate the response, especially given the stated goals/non-goals of the HPC Profile, and would be glad to participate in this afternoon's telecon. Duane ----- Original Message ----- From: Marty Humphrey To: ogsa-hpcp-wg@ggf.org Sent: Thursday, September 27, 2007 7:11 AM Subject: Re: [ogsa-hpcp-wg] Discussion of the HPC-BP security requirements(and the OGSA EAP) [[ moving this to the open mailing list ]] Duane, Thanks for approaching us about this, and your ideas are very interesting. Furthermore, your approach could be very important in the future. I appreciate your comments on the HPC Basic Profile, identifying specific text that could be improved. But I'm not sure what you're asking. I don't know exactly what "adopting the OGSA-BSP2.0 to clarify the security requirements of BES (and activity) endpoints" means. As you know, the HPC Profile is a profiling effort, by definition specifying restrictions, clarifications, additions, etc., to enable interoperability for specific HPC use-cases and specific HPC environments. In particular, the HPC Basic Profile, Section 6.2, begins with the following: "This specification takes the position that security interoperability for the Base Use Case is best achieved through a few widely deployed, standards-based, technologies and vetted implementation guidance. It is not a goal of this specification to innovate in the security area or drive adoption of new technologies." Therefore, I don't think it meets the goals of the Basic Profile to mandate or even endorse the use of EPRs in this way. Note, however, that I don't think the Basic Profile should state that EPRs cannot or should not be used this way, either. Rather, it is appropriate for the HPC Basic Profile to take no position on this use of EPRs. The composable nature of the HPC Profile WG efforts supports an "Extension" that contains a description of your approach, of course. If you are so inclined, then you and others can write such an extension and then attempt to gain support in the community for such an extension (this, of course, is the way that ANY author can develop ANY extension to the BPC Basic Profile - in fact, *I'm* doing this with the Activity Credential Extension and the Data Staging Extension). As with an OGF spec, if there's a need for this, and if it solves a problem, then it will be adopted. To summarize: I'm *not* saying that EPRs should not be used this way. I am also *not* saying that BES shouldn't do this. But BES is broader than just the HPC Profile WG (which is specifying a particular "way" to use BES, for interop purposes). I'm saying that I don't think it's consistent with the goals of the HPC Basic Profile to take one position one way or the other about this. The HPC Profile WG approach was designed for such "extensions", so I strongly encourage all interested parties to write the extension that they think is important and then do the necessary work to gain adoption of such extensions. As you know, we have a HPC Profile WG call today, and I'm sure we can find some time to discuss this. Regards, Marty From: Duane Merrill [mailto:dgm4d@virginia.edu] Sent: Wednesday, September 19, 2007 1:03 PM To: Marty Humphrey; Blair Dillaway; wasson@virginia.edu; Christopher Smith; theimer@microsoft.com Cc: 'Andrew Grimshaw' Subject: Discussion of the HPC-BP security requirements (and the OGSA EAP) Hi all, One of the action items for the OGSA Basic Security Profile 2.0 (Express Authentication Profile) is to approach the HPC-WG about adopting the OGSA-BSP2.0 to clarify the security requirements of BES (and activity) endpoints. The HPC-BP would seem to benefit from the policies and mechanisms profiled in the OGSA-BSP2.0 for conveying communication configurations to clients via EPRs. For example, (excluding TLS parameters) the HPC-BP document defines two lowest-common-denominators which have been given conformance claims: a.. Mutually-authenticated TLS b.. Server-authenticated TLS with cleartext UsernameToken and one supported variant which does not have a distinguishing conformance claim: a.. Sever-authenticated TLS with digested UsernameToken The HPC-BP "Section 3: Claiming Conformance" leverages the WS-I Conformance Claim Attachment Mechanisms Version 1.0 specification to convey the particular secure communication configuration of a given service instance. This, however, presents several issues: a.. The HPC-BP does not have a conformance claim for "Sever-authenticated TLS with digested UsernameToken". (Yet a client may prefer to use that mechanism if it's available, but it has no way of discovering so without risking failure.) a.. The WS-I Conformance Claim Attachment Mechanisms Version 1.0 specification does not describe the attachment of conformance claims to EPRs. (Rather, it describes the attachment of claims to WSDL and UDDI. I assume that the HPC-BP is suggesting the WSDL attachment mechanism, though this is not explicit.) Yet, unlike WSDL, only an EPR encapsulates the sufficient information (including reference parameters) to communicate with a service instance. Unfortunately, even if such claim-enabled WSDL for a given service is published online, there is no guaranteed way of locating that WSDL when presented with a service instance EPR. For interoperability and convenience purposes, it would be useful for EPRs to convey the particular secure communication configuration of the BES/activity service instances they reference. The OGSA-BSP2.0 defines security policies that normatively describe the above configurations and the manner in which they can be referenced within EPRs. An example EPR that conveys the "Sever-authenticated TLS with digested UsernameToken" policy using the EAP would look like: <wsa:EndpointReference ...> ... <wsa:Metadata> ... <wsp:PolicyAttachment> <wsp:AppliesTo> <wsp:URI>urn:wsaaction:*</wsp:URI> </wsp:AppliesTo> <wsp:Policy> <wsp:PolicyReference> http://www.ggf.org/ogsa/2007/05/sp-secure-transport#ServerTLS </wsp:PolicyReference> <wsp:PolicyReference> http://www.ggf.org/ogsa/2007/05/sp-secure-soap#PasswordDigest </wsp:PolicyReference> <wsp:Policy> <wsp:PolicyAttachment> </wsa:Metadata> </wsa:EndpointReference> I realize that several of you are preoccupied with Grid '07 at the moment, but Andrew and I would very much like to chat with the HPC-WG about the HPC-BP security considerations, perhaps on an upcoming HPC-WG call (e.g., 9/27). -Duane Marty Humphrey wrote: Let me be a little more verbose :^) We have something that goes live on Friday, and that's eating all of my time. So I won't have any available time to meet. Note that this is not just a 15 min discussion - it's all the time that I need to page this all back into my mind, which I don't have before I hop on a plane. Now, having said that, something in your email leaps out at me: "For interoperability and convenience purposes, it would be useful for a BES/activity endpoint reference to be able to convey the particular secure communication configuration of that service. " I don't understand this statement - are you saying that the HPC Basic Profile does not contain such discovery mechanisms? This is Section 3 - "Claiming Conformance". From: Marty Humphrey [mailto:humphrey@cs.virginia.edu] Sent: Tuesday, September 18, 2007 12:58 PM To: 'Duane Merrill' Cc: 'Andrew Grimshaw' Subject: RE: Chat about HPC-BP security requirements No - no time From: Duane Merrill [mailto:dgm4d@virginia.edu] Sent: Tuesday, September 18, 2007 12:59 PM To: humphrey@cs.virginia.edu Cc: Andrew Grimshaw Subject: Chat about HPC-BP security requirements Marty, Would it be possible to schedule a quick meeting with you before you leave for Grid '07 to chat about the HPC Basic Profile security considerations? One of the action items for the OGSA Basic Security Profile 2.0 is to approach the HPC-WG about adopting the OGSA-BSP2.0 (Express Authentication Profile) on WS-Addressing to clarify the security requirements of BES (and activity) endpoints. For example, (excluding TLS parameters) the HPC-BP document defines two lowest-common-denominators for secure communication: a.. Mutually-authenticated TLS b.. Server-authenticated TLS with cleartext UsernameToken and one supported variant: a.. Sever-authenticated TLS with digested UsernameToken For interoperability and convenience purposes, it would be useful for a BES/activity endpoint reference to be able to convey the particular secure communication configuration of that service. The OGSA-BSP2.0 defines security policies that normatively describe above configurations and the manner in which they can be referenced within EPRs. If you're free, I would much appreciate chatting with you for a few minutes at your convenience. -Duane ------------------------------------------------------------------------------ -- ogsa-hpcp-wg mailing list ogsa-hpcp-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg