Just a few comments added to Blair's reply: * nice, thorough write-up * Blair mentioned it already, but just to clarify that the embedding of key-info in the EPR allows one to use normal user-certs for ssl/tls servers and to enforce an equivalent authorization on the to-be-expected server's subject(-alt)-name. Section 2.1.i seems to hint at the same in the BSP-core discussion. * Keep it simple as far as the "what to encrypt" in the message header/body - a default of encrypt body but not header goes probably a long way and anything more "flexible" becomes soon "too" complicated. * The ability to have different creds for each resource-instance within a container was needed if you use proxy-certs as authz-assertions - in order to empower the resource-instances, the user will issue a PC associated with its resource. The alternative is to associate only the authz-assertion which each resource, like a saml-authz-assertion... or individual PCs issued on the container's creds instead of a new key(-pair). * 3.iii - embedding an EPI in a X509 cert sounds good, but not sure how that would make migration easier: don't you have to move the private key then with the resource? * if only we could get rid of the username/password requirement - the idea that after all these years we still need to be able to pass cleartext passwords over encrypted channels/messages to application services is embarrassing - passing secrets through app-services is not good - if you have more than one app-svc, are you going to move the secrets through each of them .... if you need u/p, then use myproxy/shib/kerberos or something equivalent to bootstrap and translate that in some short-term pk-creds which you use to talk to the app-svcs (or just use kerberos ;-) ). * 2.2.iii - theoretically, one could use proxy-certs issued on the service's authN-key such that there is no round trip required where the service has to communicate the newly generated public-key to the client. A PC issued on the service's authN-key would then be the equivalent of a saml-assertion issued on the service's Id. The advantage of using a PC would be that the format and semantics is well defined, while for SAML you would need another profile to standardize the equivalent assertion. (the GT4.2 trunk includes the code to move the different SAML assertion flavors as well as X509ACs in the standardized header elements - thats was the easy part - what to do with all the possible assertions on the receiving side and how to process them and use them in authZ is left as an exercise for the reader... which makes the simplicity of the PC approach soon appealing once your head starts spinning...;-) ) * could be an interesting discussion at the F2F... Regards, Frank. Blair Dillaway wrote:

Mark, Duane,

I won't be at the F2F, so wanted to provide some comments now. I do generally agree with your assessment presented in Section 2 and the need for additional work.

1. I have discussed the motivating use cases for OGSA-BSP Core with Frank Siebenlist. This was developed to support validation of the desired TLS/SSL server where the server cert doesn't contain info corresponding to the service location. I happen to think standardizing on such a mechanism may be more important when using message-level security, but that may require some additional work as you mention.

2. With regard to your HPC Basic Profile comments in 2.3. Its important to remember the primary motivation for the specified security mechanisms was to support near term interoperability between the different implementers consistent with the HPC base use case. Waiting for a more general solution to be developed was not a viable option.

3. There is likely to be significant overlap between what you propose in Section 3 of this document and the deliverables of the OGSA-AuthN WG based on the BoF at OGF19. In particular, it was agreed one of the deliverables should be SOAP message WS-Security profiles for conveying the various types of authentication and supporting credentials needed for grid use cases. As with your proposal, this would be WS-I BSP security conformant. I therefore strongly urge you to integrate your proposed work on "a straightforward application of the WS-I BSP's SOAP messaging security considerations to the grid domain" and "OGSA BSP-SC profile to reflect an approach similar to the current HPC-BP" into the OGSA-AuthN proposed deliverable.

The "endpoint reference security considerations" you wish to profile, also seem in scope of the OGSA-AuthN effort. If you are willing to work on these, I see no reason we shouldn't include a deliverable for this work in the charter currently being prepared. I'd rather see us build AuthN related critical mass in a single WG rather than split this across multiple WGs.

4. I hope that last sentence in your email doesn't imply writing a new standard that is "consistent with Globus GT 4" is a goal? The goal should be to develop a standard providing a basis for interoperability across a variety of grid middleware solutions. I hope Globus is one of those, but there's not much point in the effort if that's the only implementation.

Regards, Blair Dillaway Security AD

...

-----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Mark Morgan Sent: Thursday, March 08, 2007 5:02 AM To: ogsa-wg@ggf.org Subject: [ogsa-wg] Draft, Informational, Security Profile

Ladies and Gentlemen,

Please find attached a draft copy of an informational document detailing a recommendation that the GBG group at the University of Virginia would like to discuss next week at the OGSA F2F. To the best of our knowledge, based on documents sent by Mr. Ian Foster, this document describes ways of filling in gaps that exist in the current OGSA security documents that are consistent with Globus GT 4.

-Mark and Duane

-- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a@virginia.edu (434) 982-2047 -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg

-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

Duane Merrill III wrote:

----- Original Message ----- From: "Frank Siebenlist" <franks@mcs.anl.gov <mailto:franks@mcs.anl.gov>>

...

* Blair mentioned it already, but just to clarify that the embedding of key-info in the EPR allows one to use normal user-certs for ssl/tls servers and to enforce an equivalent authorization on the to-be-expected server's subject(-alt)-name. Section 2.1.i seems to hint at the same in the BSP-core discussion.

...

...

----- Original Message ----- From: "Blair Dillaway" <blaird@microsoft.com <mailto:blaird@microsoft.com>> 1. I have discussed the motivating use cases for OGSA-BSP Core with Frank Siebenlist. This was developed to support validation of the desired TLS/SSL server where the server cert doesn't contain info corresponding to the service location. I happen to think standardizing on such a mechanism may be more important when using message-level security, but that may require some additional work as you mention.

Very interesting. I had no idea that the OGSA BSP-Core was specifically motivated for SSL/TLS transport level security. I had just assumed that the profile was primarily addressing an intuitive approach for communicating key/certificate information to clients for use in SOAP message-level secure commmunication. (The words "SSL" or "TLS" never appear in the document, and "transport" appears once in line 107 in a manner that would appear to be descriptive of the OGSA BSP-SC profile, rather than the Core profile.)

I agree that this is not clearly evident from the docs - the idea is that the BSP-SC profile leverages and depends on the BSP-Core, and not the other way around - so the BSP-Core should not discuss SSL/TLS. More use case descriptions would indeed make it more palatable - right now the legalese is almost unbearable for mere mortals... -Frank.

In fact, it seems that the OGSA HPC Basic Profile document made the same initial assumption that I did, as it reads:

/Note: The OGSA Basic Security Profile 1.0 - Core specification is not used as that addresses the binding of key information to an endpoint reference [in WS-Addressing], which is not relevant when using transport layer security./

This further evidences the need for more specificity in the BSP-Core profile for the intent-of-use of the embedded key (cert) information. (For example, a client may want to see /two/ certificates within the endpoint references that it consumes: one to verify the SSL/TLS endpoint, and the other to authenticate the individual, possibly-mobile, remote resource.) We would suggest that the OGSA BSP-SC be updated to explicitly reflect this interaction with the (proposed updates to the) BSP-Core; specifically that there must be agreement between any such server subject-(alt-)names in embedded EPR key/cert information that is specified for transport endpoint verification. By doing this, the application of these two profiles would explicitly address your original tranport security motivations.

-Duane

-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory

----- Original Message ----- From: "Frank Siebenlist" <franks@mcs.anl.gov>

* 2.2.iii - theoretically, one could use proxy-certs issued on the service's authN-key such that there is no round trip required where the service has to communicate the newly generated public-key to the client. A PC issued on the service's authN-key would then be the equivalent of a saml-assertion issued on the service's Id. The advantage of using a PC would be that the format and semantics is well defined, while for SAML you would need another profile to standardize the equivalent assertion. (the GT4.2 trunk includes the code to move the different SAML assertion flavors as well as X509ACs in the standardized header elements - thats was the easy part - what to do with all the possible assertions on the receiving side and how to process them and use them in authZ is left as an exercise for the reader... which makes the simplicity of the PC approach soon appealing once your head starts spinning...;-) )

Yes. Theoretically any trust-based credential can be "pre-authorized" for delegation by signing in the delegatee's public AuthN key. (In fact, we do this for SAML credentials in Genesis II.) Personally, I am in favor of this "one-way" delegation process; it avoids the round-trip associated with the certificate-signing-request that you mention. The certificate-signing-request, when performed at the SOAP message level, would require that clients expose listening transport sockets, accept incoming messages, and implement message nonces for correlating incoming certificate-signing-requests with previously-sent outgoing messages. All of this may be undesirable for complexity, efficiency, firewall, etc. reasons. (Performing the certificate-signing-request at the SOAP message-level is necessary for per-resource delegation; delegation at the transport-level is not effective for that purpose.) However, there is a small drawback to this one-way approach to consider. Under the traditional certificate-signing-request approach, the delegatee can simply "throw-away" the generated private delegation key when it is finished using the delegated credential. Thus any future compromise of the delegatee would not compromise the credential delegated to it (as the delegation private key no longer exists to be compromised). In the "one-way" approach, the delegatee can not throw away the delegation private key because it corresponds to its well-known, published AuthN public key. Therefore the "one-way" approach is slightly more vulnerable to delegatee compromise (assuming that everyone who uses the certificate-signing-request approach "plays nice" and destroys their delegation keys in a timely manner). An interesting hybrid approach that we are evaluating within Genesis II is to have the delegator generate a new delegation keypair and sign both the new delegation public key as well as the public key of the delegatee into the delegation credential. Assuming a confidential channel with the delegatee, the delegator sends both the delegation credential and the delegation private key to the delegatee. (The delegator would then destroy its copy of the delegation private key.) The delegatee can then be authenticated with the delegation credential by signing its outgoing messages twice: once with its own AuthN private key and again with the delegation private key. When finished, the delegation private key can be destroyed and the delegation credential is safe from future compromise of the delegatee. Thus we preserve both the one-way semantic of "pre-authorization" and the marginal benefits of the certificate-signing-request approach where delegatees can be trusted to discard delegation private keys when finished using delegation credentials. (It is very likely that the common-case will involve limited-lifetime credentials anyway, so any un-enforceable delegation-key-destroying policy would provide marginal benefits at best.) Of course, delegation credentials are out of scope for our proposed OGSA Basic SOAP Security profile. The BSSP would ideally be a living document that incorporates external credential profiles (e.g., the security tokens covered in the WSI BSP) as they are developed. (Developing OGSA delegation credential profiles for X.509 proxy certificates and SAML holder-of-key assertions would be a Good Thing. Developing OGSA credential profiles for any credential, even if they simply inherit from the WSI BSP would be a Good Thing.) -Duane