[ogsa-hpcp-wg] Discussion of the HPC-BP security requirements (and the OGSA EAP)

Thu Sep 27 06:11:06 CDT 2007

[[ 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 at virginia.edu] 
Sent: Wednesday, September 19, 2007 1:03 PM
To: Marty Humphrey; Blair Dillaway; wasson at virginia.edu; Christopher Smith;
theimer at 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: 

*	Mutually-authenticated TLS
*	Server-authenticated TLS with cleartext UsernameToken

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

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

*	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.)

*	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 at 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 at virginia.edu] 
Sent: Tuesday, September 18, 2007 12:59 PM
To: humphrey at 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:

*	Mutually-authenticated TLS
*	Server-authenticated TLS with cleartext UsernameToken

and one supported variant:

*	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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-hpcp-wg/attachments/20070927/0493d773/attachment-0001.html 