[ogsa-wg] Draft, Informational, Security Profile

Fri Mar 9 01:21:00 CST 2007

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 at ogf.org [mailto:ogsa-wg-bounces at ogf.org] On
>> Behalf Of Mark Morgan
>> Sent: Thursday, March 08, 2007 5:02 AM
>> To: ogsa-wg at 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 at virginia.edu
>> (434) 982-2047
> --
>   ogsa-wg mailing list
>   ogsa-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-wg
> 

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