[[ 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:

 

and one supported variant which does not have a distinguishing conformance claim:


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:


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:

and one supported variant:

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