(adding the other authors back to this thread) This discussion, and a side conversation with Alan, makes me think a little more context may be useful. I can agree with the comments by Alan and others since I believe they are considering different requirements and priorities. As background, I first discussed the HPC Profile WG's security requirements with the chairpersons at SC06. A reason for that discussion was to see if their requirements could be met as part of the more general OGSA-AuthN proposal, OGSA-AuthZ, etc. While we generally agreed those efforts may meet the security requirements in the long term, the HPC Profile WG needs a very near term interoperability solution for the HPC base use case. That use case only considers intra-domain use of HPC compute resources with batch job scheduling. The solution also needs to be compatible with existing products and customer environments to allow for rapid adoption. These requirements drove the draft the document under discussion. The rationale for supporting TLS/SSL and X.509-based authentication is probably well understood and not terribly controversial. There are a couple of important reasons for also supporting username-password client authentication. First, some existing HPC products only support this mechanism. Second, many organizations are unwilling to deploy and manage an X.509 client certification infrastructure solely for internal access control. Its perfectly reasonable to debate the HPC requirements and the proposed authN mechanisms, but that isn't the focus of this thread. As Alan has stated, he is focused on grid authN use cases. I agree with him, and the reasons cited, why username-password authN is inappropriate for many grid environments. I think the only real issue here is whether there are interesting grid uses cases for which the proposed HPC profile authN mechanisms are suitable. If so, then perhaps broader usage guidance appropriate should be incorporated into the document. I do agree its inappropriate to ask the HPC Profile WG to wait for some future activity to address their current needs. Regards, Blair Dillaway -----Original Message----- From: ogsa-authn-bof-bounces@ogf.org [mailto:ogsa-authn-bof-bounces@ogf.org] On Behalf Of Von Welch Sent: Monday, January 22, 2007 11:39 AM To: Steven Newhouse Cc: OGSA Authentication WG BoF; ogsa-wg@gridforum.org Subject: Re: [ogsa-authn-bof] [ogsa-wg] Authentication in OGSA [Dropped security-area from cc list. Please leave it off.] I agree with Steven. We need to separate what is specified from what is acceptable in certain deployment scenarios. There certainly are deployment scenarios where PKI is required, just as there are scenarios where it is undesirable. I think the choice of focus on PKI and username/password offers promise of supporting a broad range of deployment scenarios. Von On Jan 22, 2007, at 1:32 PM, Steven Newhouse wrote:
I specifically think these additions are not supported, nor are they supportable, for high-performance computing resource access under OGSA either in philosophy or in implementation as written.
'access under OGSA' is a bit of a null statement IMHO. Both of the proposed mechanisms (username/password & X.509 certificates) are viable in some deployment scenarios - perhaps not in others. The key requirement is to keep moving.
Waiting for the results of WG's that are just having BoFs is not really a viable solution.
Steven -- ---------------------------------------------------------------- Dr Steven Newhouse Mob:+44(0)7920489420 Tel:+44(0)23 80598789 Director, Open Middleware Infrastructure Institute-UK (OMII-UK) c/o Suite 6005, Faraday Building (B21), Highfield Campus, University of Southampton, Highfield, Southampton, SO17 1BJ, UK
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
_______________________________________________ ogsa-authn-bof mailing list ogsa-authn-bof@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authn-bof