Authentication in OGSA
All, On this mornings call I volunteered to see what was up with the HPC profile working group with respect to authentication. Recall that we need some sort of authentication story in the short run or we cannot put together any form or realistic, cross-organizational, compute grids with BES, or for that matter data grids using RNS/ByteIO. Attached is a short white paper from the HPC Profile WG (or maybe just the three authors). It is BES-specific, but I think the ideas may be generalized to a broader set of OGSA services. I think we should consider it, or something like it. Note that it does NOT deal with the ultimate authentication and delegation problem that we will face. Rather, I personally (speaking only for myself, and not even the people in my research group) think that this sort of solution is a stop gap that we can use for awhile, and that we will ultimately deprecate in favor of whatever comes out of the OGSA-Authentication WG. So, for your reading pleasure - and with my thanks to Marty for giving me a copy. A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw@cs.virginia.edu
Hi Andrew and the OGSA-WG, I apologize for missing the meeting last Thursday on this topic. We have a machine full of new cluster and grid equipment, and I have been fully occupied commissioning and configuring it. I am afraid that I differ rather strongly with the direction being taken with regard to the HPC profile at this stage. My view is strongly that simple username/password login, even SSL secured, is quite demonstrably insufficiently secure to deploy as a model for authentication and access to high performance computing. I disagree fairly strongly that any sort of stop-gap of this nature should be written into the HPC profile, distributed or promoted at this time. I have an excuse for having taken so long to reply on this topic. It was necessary for me to investigate as thoroughly as possible the current state of deployment of GSI-secured alternatives to username/ password login and to do so in a way that would allow me to give a credible response to all of you regarding the state of the art on this topic. At this point I am assured and feel sufficiently confident to proceed, either at OGF-19 or before, with Andrew, Marty, and whoever else would like to participate on a revision of the HPC profile that would cover more secure basic access to high performance cluster and storage systems based on GSIOpenSSH and similar software that uses either GT4 or an equivalent callout. We are writing standards, not implementations, but I wished to be sure that the state of the art on existing implementations would be consistent with making this recommendation. It is essential from my point of view to promote secure access to HPC resources. As the bulk of the compromise attacks that have been successful over the past 2 to 3 years on HPC resources has been through discovery and reuse of username/password combinations from ordinary users (at least as I read the recent record), I think that now is not the right time to propose backing off from the use of strong cryptographic methods to use HPC resources in grid settings. The use of strong cryptography does not have to be limited to X.509 "pure classic" PKI, and I look forward to an active discussion on federated identity and related topics to be held at the OGF meeting next week. It is clear to me that recent improvements to the availability and technology for authentication, authorization and attribute transmission will make many modes of access to grid resources possible with appropriate security that up to now have been either impossible or confined to limited implementation. For the moment, I would like to suggest that a revision of the HPC profile propose that "only GSI or equivalently secure architectures be used for direct access to HPC resources" and that the document be revised specifically to discourage the direct access by users to highly capable computational and to secure storage resources by username/password mechanisms. In my own project, we use GSI-OpenSSH via grid-mapfiles. I have been able to confirm that current implementations of GSI-OpenSSH are capable of interoperating with more general callout-based systems, including attribute-based AuthZ systems, without modification. Therefore it is not necessary for users to have username/password access if direct login is needed on an HPC system. As a further enhancement to the document and to the profile, I feel it would be useful to describe architectures for pure-computational (i.e., batch-only access), for pure-login (i.e., front-end and submission access), pure-storage (i.e., stage-in/stage-out and related data handling) and for the interesting use case of "managed fork" (i.e., interactive but sand-boxed grid access) systems. I believe these changes would result in an improved HPC profile that would be of better total usability within the HPC community. This document is NOT attached, instead your original one is for discussion, but I believe can be worked out in the context of discussions to be held at OGF-19 next week. Sorry for being (apparently but not really) strident, but I believe the above reflects current best practices better than recommending username/password support for direct login to HPC systems. I would not personally be able to support the current draft as written. Thanks and best wishes, Alan On Jan 18, 2007, at 2:16 PM, Andrew Grimshaw wrote:
All,
On this mornings call I volunteered to see what was up with the HPC profile working group with respect to authentication. Recall that we need some sort of authentication story in the short run or we cannot put together any form or realistic, cross-organizational, compute grids with BES, or for that matter data grids using RNS/ ByteIO.
Attached is a short white paper from the HPC Profile WG (or maybe just the three authors). It is BES-specific, but I think the ideas may be generalized to a broader set of OGSA services. I think we should consider it, or something like it.
Note that it does NOT deal with the ultimate authentication and delegation problem that we will face. Rather, I personally (speaking only for myself, and not even the people in my research group) think that this sort of solution is a stop gap that we can use for awhile, and that we will ultimately deprecate in favor of whatever comes out of the OGSA-Authentication WG.
So, for your reading pleasure – and with my thanks to Marty for giving me a copy.
A
Andrew Grimshaw
Professor of Computer Science
University of Virginia
434-982-2204
grimshaw@cs.virginia.edu
--
ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
Hi Alan, Andrew, and Marty, OGSA Security Profile - secure channel is certificate base and I think HPCP WG can utilize (and maybe extents) it for your interoperability purpose. If you can make this Thursday call, we will allocate some time for this discussion. If Thursday does not for you, please come to OGSA security session (Mon 29 Jan, 2pm) at OGF19 for farther discussion. Thanks, ---- Hiro Kishimoto Alan Sill wrote:
Hi Andrew and the OGSA-WG,
I apologize for missing the meeting last Thursday on this topic. We have a machine full of new cluster and grid equipment, and I have been fully occupied commissioning and configuring it.
I am afraid that I differ rather strongly with the direction being taken with regard to the HPC profile at this stage. My view is strongly that simple username/password login, even SSL secured, is quite demonstrably insufficiently secure to deploy as a model for authentication and access to high performance computing. I disagree fairly strongly that any sort of stop-gap of this nature should be written into the HPC profile, distributed or promoted at this time.
I have an excuse for having taken so long to reply on this topic. It was necessary for me to investigate as thoroughly as possible the current state of deployment of GSI-secured alternatives to username/password login and to do so in a way that would allow me to give a credible response to all of you regarding the state of the art on this topic.
At this point I am assured and feel sufficiently confident to proceed, either at OGF-19 or before, with Andrew, Marty, and whoever else would like to participate on a revision of the HPC profile that would cover more secure basic access to high performance cluster and storage systems based on GSIOpenSSH and similar software that uses either GT4 or an equivalent callout. We are writing standards, not implementations, but I wished to be sure that the state of the art on existing implementations would be consistent with making this recommendation.
It is essential from my point of view to promote secure access to HPC resources. As the bulk of the compromise attacks that have been successful over the past 2 to 3 years on HPC resources has been through discovery and reuse of username/password combinations from ordinary users (at least as I read the recent record), I think that now is not the right time to propose backing off from the use of strong cryptographic methods to use HPC resources in grid settings. The use of strong cryptography does not have to be limited to X.509 "pure classic" PKI, and I look forward to an active discussion on federated identity and related topics to be held at the OGF meeting next week. It is clear to me that recent improvements to the availability and technology for authentication, authorization and attribute transmission will make many modes of access to grid resources possible with appropriate security that up to now have been either impossible or confined to limited implementation.
For the moment, I would like to suggest that a revision of the HPC profile propose that "only GSI or equivalently secure architectures be used for direct access to HPC resources" and that the document be revised specifically to discourage the direct access by users to highly capable computational and to secure storage resources by username/password mechanisms. In my own project, we use GSI-OpenSSH via grid-mapfiles. I have been able to confirm that current implementations of GSI-OpenSSH are capable of interoperating with more general callout-based systems, including attribute-based AuthZ systems, without modification. Therefore it is not necessary for users to have username/password access if direct login is needed on an HPC system.
As a further enhancement to the document and to the profile, I feel it would be useful to describe architectures for pure-computational (i.e., batch-only access), for pure-login (i.e., front-end and submission access), pure-storage (i.e., stage-in/stage-out and related data handling) and for the interesting use case of "managed fork" (i.e., interactive but sand-boxed grid access) systems. I believe these changes would result in an improved HPC profile that would be of better total usability within the HPC community. This document is NOT attached, instead your original one is for discussion, but I believe can be worked out in the context of discussions to be held at OGF-19 next week.
Sorry for being (apparently but not really) strident, but I believe the above reflects current best practices better than recommending username/password support for direct login to HPC systems. I would not personally be able to support the current draft as written.
Thanks and best wishes, Alan
On Jan 18, 2007, at 2:16 PM, Andrew Grimshaw wrote:
All,
On this mornings call I volunteered to see what was up with the HPC profile working group with respect to authentication. Recall that we need some sort of authentication story in the short run or we cannot put together any form or realistic, cross-organizational, compute grids with BES, or for that matter data grids using RNS/ByteIO.
Attached is a short white paper from the HPC Profile WG (or maybe just the three authors). It is BES-specific, but I think the ideas may be generalized to a broader set of OGSA services. I think we should consider it, or something like it.
Note that it does NOT deal with the ultimate authentication and delegation problem that we will face. Rather, I personally (speaking only for myself, and not even the people in my research group) think that this sort of solution is a stop gap that we can use for awhile, and that we will ultimately deprecate in favor of whatever comes out of the OGSA-Authentication WG.
So, for your reading pleasure – and with my thanks to Marty for giving me a copy.
A
Andrew Grimshaw
Professor of Computer Science
University of Virginia
434-982-2204
grimshaw@cs.virginia.edu
--
ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU
==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
------------------------------------------------------------------------
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Hi All, In helping to draft the HPC Basic Profile security specification under consideration, I did review the latest drafts of the OGSA-BSP-Secure Channel specification. The HPC security proposal is compatible with the recommendations in that document as cited in the text, though it allows for some additional functionality. This was deemed necessary, after discussion with the HPC Profile WG chairpersons, to adequately support interoperability between existing products. Specific differences include: - Mutual authN based on X.509 certificates is not required, as a client username/password option is provided - TLS 1.0 is not mandatory when establishing an HTTP-based connection. SSL3.0 and TLS 1.1 are also allowed The mandatory and optional TLS/SSL cipher suites and guidance in OGS-BSP-SC are adopted. I hope that background helps facilitate discussion of the proposal. It is certainly worth discussing whether we can bring these two documents into even tighter alignment while still fully meeting the needs each was intended to address. Regards, Blair Dillaway -----Original Message----- From: ogsa-authn-bof-bounces@ogf.org [mailto:ogsa-authn-bof-bounces@ogf.org] On Behalf Of Hiro Kishimoto Sent: Monday, January 22, 2007 1:33 AM To: Alan Sill; Andrew Grimshaw; Marty Humphrey Cc: OGSA Authentication WG BoF; security-area@ogf.org; ogsa-wg@gridforum.org Subject: Re: [ogsa-authn-bof] [ogsa-wg] Authentication in OGSA Hi Alan, Andrew, and Marty, OGSA Security Profile - secure channel is certificate base and I think HPCP WG can utilize (and maybe extents) it for your interoperability purpose. If you can make this Thursday call, we will allocate some time for this discussion. If Thursday does not for you, please come to OGSA security session (Mon 29 Jan, 2pm) at OGF19 for farther discussion. Thanks, ---- Hiro Kishimoto Alan Sill wrote:
Hi Andrew and the OGSA-WG,
I apologize for missing the meeting last Thursday on this topic. We have a machine full of new cluster and grid equipment, and I have been
fully occupied commissioning and configuring it.
I am afraid that I differ rather strongly with the direction being taken with regard to the HPC profile at this stage. My view is strongly that simple username/password login, even SSL secured, is quite demonstrably insufficiently secure to deploy as a model for authentication and access to high performance computing. I disagree fairly strongly that any sort of stop-gap of this nature should be written into the HPC profile, distributed or promoted at this time.
I have an excuse for having taken so long to reply on this topic. It was necessary for me to investigate as thoroughly as possible the current state of deployment of GSI-secured alternatives to username/password login and to do so in a way that would allow me to give a credible response to all of you regarding the state of the art on this topic.
At this point I am assured and feel sufficiently confident to proceed,
either at OGF-19 or before, with Andrew, Marty, and whoever else would
like to participate on a revision of the HPC profile that would cover more secure basic access to high performance cluster and storage systems based on GSIOpenSSH and similar software that uses either GT4 or an equivalent callout. We are writing standards, not implementations, but I wished to be sure that the state of the art on existing implementations would be consistent with making this recommendation.
It is essential from my point of view to promote secure access to HPC resources. As the bulk of the compromise attacks that have been successful over the past 2 to 3 years on HPC resources has been through discovery and reuse of username/password combinations from ordinary users (at least as I read the recent record), I think that now is not the right time to propose backing off from the use of strong cryptographic methods to use HPC resources in grid settings. The use of strong cryptography does not have to be limited to X.509 "pure classic" PKI, and I look forward to an active discussion on federated identity and related topics to be held at the OGF meeting next week. It is clear to me that recent improvements to the availability and technology for authentication, authorization and attribute transmission will make many modes of access to grid resources possible with appropriate security that up to now have been either impossible or confined to limited implementation.
For the moment, I would like to suggest that a revision of the HPC profile propose that "only GSI or equivalently secure architectures be
used for direct access to HPC resources" and that the document be revised specifically to discourage the direct access by users to highly capable computational and to secure storage resources by username/password mechanisms. In my own project, we use GSI-OpenSSH via grid-mapfiles. I have been able to confirm that current implementations of GSI-OpenSSH are capable of interoperating with more general callout-based systems, including attribute-based AuthZ systems, without modification. Therefore it is not necessary for users to have username/password access if direct login is needed on an HPC system.
As a further enhancement to the document and to the profile, I feel it
would be useful to describe architectures for pure-computational (i.e., batch-only access), for pure-login (i.e., front-end and submission access), pure-storage (i.e., stage-in/stage-out and related data handling) and for the interesting use case of "managed fork" (i.e., interactive but sand-boxed grid access) systems. I believe these changes would result in an improved HPC profile that would be of better total usability within the HPC community. This document is NOT attached, instead your original one is for discussion, but I believe can be worked out in the context of discussions to be held at OGF-19 next week.
Sorry for being (apparently but not really) strident, but I believe the above reflects current best practices better than recommending username/password support for direct login to HPC systems. I would not personally be able to support the current draft as written.
Thanks and best wishes, Alan
On Jan 18, 2007, at 2:16 PM, Andrew Grimshaw wrote:
All,
On this mornings call I volunteered to see what was up with the HPC profile working group with respect to authentication. Recall that we
need some sort of authentication story in the short run or we cannot put together any form or realistic, cross-organizational, compute grids with BES, or for that matter data grids using RNS/ByteIO.
Attached is a short white paper from the HPC Profile WG (or maybe just the three authors). It is BES-specific, but I think the ideas may be generalized to a broader set of OGSA services. I think we should consider it, or something like it.
Note that it does NOT deal with the ultimate authentication and delegation problem that we will face. Rather, I personally (speaking only for myself, and not even the people in my research group) think that this sort of solution is a stop gap that we can use for awhile, and that we will ultimately deprecate in favor of whatever comes out of the OGSA-Authentication WG.
So, for your reading pleasure - and with my thanks to Marty for giving me a copy.
A
Andrew Grimshaw
Professor of Computer Science
University of Virginia
434-982-2204
grimshaw@cs.virginia.edu
--
ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU
==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
------------------------------------------------------------------------
-- 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
Let us look for a compromise at OGF-19 on this issue. 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. It is possible that sufficient attention to qualification on the topics of levels of assurance (for which there is a BOF), identity management (for which in the Federated ID systems there is an all-day session), and/or tying the username/password to systems of sufficient strength for identity management and verification could allow a qualified extension of this use case to be written to support username/password access in selected cases. Best, Alan On Jan 22, 2007, at 11:46 AM, Blair Dillaway wrote:
Hi All,
In helping to draft the HPC Basic Profile security specification under consideration, I did review the latest drafts of the OGSA-BSP-Secure Channel specification. The HPC security proposal is compatible with the recommendations in that document as cited in the text, though it allows for some additional functionality. This was deemed necessary, after discussion with the HPC Profile WG chairpersons, to adequately support interoperability between existing products.
Specific differences include: - Mutual authN based on X.509 certificates is not required, as a client username/password option is provided - TLS 1.0 is not mandatory when establishing an HTTP-based connection. SSL3.0 and TLS 1.1 are also allowed
The mandatory and optional TLS/SSL cipher suites and guidance in OGS-BSP-SC are adopted.
I hope that background helps facilitate discussion of the proposal. It is certainly worth discussing whether we can bring these two documents into even tighter alignment while still fully meeting the needs each was intended to address.
Regards, Blair Dillaway
-----Original Message----- From: ogsa-authn-bof-bounces@ogf.org [mailto:ogsa-authn-bof-bounces@ogf.org] On Behalf Of Hiro Kishimoto Sent: Monday, January 22, 2007 1:33 AM To: Alan Sill; Andrew Grimshaw; Marty Humphrey Cc: OGSA Authentication WG BoF; security-area@ogf.org; ogsa-wg@gridforum.org Subject: Re: [ogsa-authn-bof] [ogsa-wg] Authentication in OGSA
Hi Alan, Andrew, and Marty,
OGSA Security Profile - secure channel is certificate base and I think HPCP WG can utilize (and maybe extents) it for your interoperability purpose.
If you can make this Thursday call, we will allocate some time for this discussion. If Thursday does not for you, please come to OGSA security session (Mon 29 Jan, 2pm) at OGF19 for farther discussion.
Thanks, ---- Hiro Kishimoto
Alan Sill wrote:
Hi Andrew and the OGSA-WG,
I apologize for missing the meeting last Thursday on this topic. We have a machine full of new cluster and grid equipment, and I have been
fully occupied commissioning and configuring it.
I am afraid that I differ rather strongly with the direction being taken with regard to the HPC profile at this stage. My view is strongly that simple username/password login, even SSL secured, is quite demonstrably insufficiently secure to deploy as a model for authentication and access to high performance computing. I disagree fairly strongly that any sort of stop-gap of this nature should be written into the HPC profile, distributed or promoted at this time.
I have an excuse for having taken so long to reply on this topic. It was necessary for me to investigate as thoroughly as possible the current state of deployment of GSI-secured alternatives to username/password login and to do so in a way that would allow me to give a credible response to all of you regarding the state of the art on this topic.
At this point I am assured and feel sufficiently confident to proceed,
either at OGF-19 or before, with Andrew, Marty, and whoever else would
like to participate on a revision of the HPC profile that would cover more secure basic access to high performance cluster and storage systems based on GSIOpenSSH and similar software that uses either GT4 or an equivalent callout. We are writing standards, not implementations, but I wished to be sure that the state of the art on existing implementations would be consistent with making this recommendation.
It is essential from my point of view to promote secure access to HPC resources. As the bulk of the compromise attacks that have been successful over the past 2 to 3 years on HPC resources has been through discovery and reuse of username/password combinations from ordinary users (at least as I read the recent record), I think that now is not the right time to propose backing off from the use of strong cryptographic methods to use HPC resources in grid settings. The use of strong cryptography does not have to be limited to X.509 "pure classic" PKI, and I look forward to an active discussion on federated identity and related topics to be held at the OGF meeting next week. It is clear to me that recent improvements to the availability and technology for authentication, authorization and attribute transmission will make many modes of access to grid resources possible with appropriate security that up to now have been either impossible or confined to limited implementation.
For the moment, I would like to suggest that a revision of the HPC profile propose that "only GSI or equivalently secure architectures be
used for direct access to HPC resources" and that the document be revised specifically to discourage the direct access by users to highly capable computational and to secure storage resources by username/password mechanisms. In my own project, we use GSI-OpenSSH via grid-mapfiles. I have been able to confirm that current implementations of GSI-OpenSSH are capable of interoperating with more general callout-based systems, including attribute-based AuthZ systems, without modification. Therefore it is not necessary for users to have username/password access if direct login is needed on an HPC system.
As a further enhancement to the document and to the profile, I feel it
would be useful to describe architectures for pure-computational (i.e., batch-only access), for pure-login (i.e., front-end and submission access), pure-storage (i.e., stage-in/stage-out and related data handling) and for the interesting use case of "managed fork" (i.e., interactive but sand-boxed grid access) systems. I believe these changes would result in an improved HPC profile that would be of better total usability within the HPC community. This document is NOT attached, instead your original one is for discussion, but I believe can be worked out in the context of discussions to be held at OGF-19 next week.
Sorry for being (apparently but not really) strident, but I believe the above reflects current best practices better than recommending username/password support for direct login to HPC systems. I would not personally be able to support the current draft as written.
Thanks and best wishes, Alan
On Jan 18, 2007, at 2:16 PM, Andrew Grimshaw wrote:
All,
On this mornings call I volunteered to see what was up with the HPC profile working group with respect to authentication. Recall that we
need some sort of authentication story in the short run or we cannot put together any form or realistic, cross-organizational, compute grids with BES, or for that matter data grids using RNS/ByteIO.
Attached is a short white paper from the HPC Profile WG (or maybe just the three authors). It is BES-specific, but I think the ideas may be generalized to a broader set of OGSA services. I think we should consider it, or something like it.
Note that it does NOT deal with the ultimate authentication and delegation problem that we will face. Rather, I personally (speaking only for myself, and not even the people in my research group) think that this sort of solution is a stop gap that we can use for awhile, and that we will ultimately deprecate in favor of whatever comes out of the OGSA-Authentication WG.
So, for your reading pleasure - and with my thanks to Marty for giving me a copy.
A
Andrew Grimshaw
Professor of Computer Science
University of Virginia
434-982-2204
grimshaw@cs.virginia.edu
--
ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
I would agree a face-to-face discussion at OGF19 is likely to be the most efficient way of making progress on this. Regards, Blair Dillaway -----Original Message----- From: Alan Sill [mailto:Alan.Sill@ttu.edu] Sent: Monday, January 22, 2007 10:12 AM To: Blair Dillaway Cc: Alan Sill; Hiro Kishimoto; Andrew Grimshaw; Marty Humphrey; OGSA Authentication WG BoF; security-area@ogf.org; ogsa-wg@gridforum.org Subject: Re: [ogsa-authn-bof] [ogsa-wg] Authentication in OGSA Let us look for a compromise at OGF-19 on this issue. 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. It is possible that sufficient attention to qualification on the topics of levels of assurance (for which there is a BOF), identity management (for which in the Federated ID systems there is an all-day session), and/or tying the username/password to systems of sufficient strength for identity management and verification could allow a qualified extension of this use case to be written to support username/password access in selected cases. Best, Alan On Jan 22, 2007, at 11:46 AM, Blair Dillaway wrote:
Hi All,
In helping to draft the HPC Basic Profile security specification under consideration, I did review the latest drafts of the OGSA-BSP-Secure Channel specification. The HPC security proposal is compatible with the recommendations in that document as cited in the text, though it allows for some additional functionality. This was deemed necessary, after discussion with the HPC Profile WG chairpersons, to adequately support interoperability between existing products.
Specific differences include: - Mutual authN based on X.509 certificates is not required, as a client username/password option is provided - TLS 1.0 is not mandatory when establishing an HTTP-based connection. SSL3.0 and TLS 1.1 are also allowed
The mandatory and optional TLS/SSL cipher suites and guidance in OGS-BSP-SC are adopted.
I hope that background helps facilitate discussion of the proposal. It is certainly worth discussing whether we can bring these two documents into even tighter alignment while still fully meeting the needs each was intended to address.
Regards, Blair Dillaway
-----Original Message----- From: ogsa-authn-bof-bounces@ogf.org [mailto:ogsa-authn-bof-bounces@ogf.org] On Behalf Of Hiro Kishimoto Sent: Monday, January 22, 2007 1:33 AM To: Alan Sill; Andrew Grimshaw; Marty Humphrey Cc: OGSA Authentication WG BoF; security-area@ogf.org; ogsa-wg@gridforum.org Subject: Re: [ogsa-authn-bof] [ogsa-wg] Authentication in OGSA
Hi Alan, Andrew, and Marty,
OGSA Security Profile - secure channel is certificate base and I think HPCP WG can utilize (and maybe extents) it for your interoperability purpose.
If you can make this Thursday call, we will allocate some time for this discussion. If Thursday does not for you, please come to OGSA security session (Mon 29 Jan, 2pm) at OGF19 for farther discussion.
Thanks, ---- Hiro Kishimoto
Alan Sill wrote:
Hi Andrew and the OGSA-WG,
I apologize for missing the meeting last Thursday on this topic. We have a machine full of new cluster and grid equipment, and I have been
fully occupied commissioning and configuring it.
I am afraid that I differ rather strongly with the direction being taken with regard to the HPC profile at this stage. My view is strongly that simple username/password login, even SSL secured, is quite demonstrably insufficiently secure to deploy as a model for authentication and access to high performance computing. I disagree fairly strongly that any sort of stop-gap of this nature should be written into the HPC profile, distributed or promoted at this time.
I have an excuse for having taken so long to reply on this topic. It was necessary for me to investigate as thoroughly as possible the current state of deployment of GSI-secured alternatives to username/password login and to do so in a way that would allow me to give a credible response to all of you regarding the state of the art on this topic.
At this point I am assured and feel sufficiently confident to proceed,
either at OGF-19 or before, with Andrew, Marty, and whoever else would
like to participate on a revision of the HPC profile that would cover more secure basic access to high performance cluster and storage systems based on GSIOpenSSH and similar software that uses either GT4 or an equivalent callout. We are writing standards, not implementations, but I wished to be sure that the state of the art on existing implementations would be consistent with making this recommendation.
It is essential from my point of view to promote secure access to HPC resources. As the bulk of the compromise attacks that have been successful over the past 2 to 3 years on HPC resources has been through discovery and reuse of username/password combinations from ordinary users (at least as I read the recent record), I think that now is not the right time to propose backing off from the use of strong cryptographic methods to use HPC resources in grid settings. The use of strong cryptography does not have to be limited to X.509 "pure classic" PKI, and I look forward to an active discussion on federated identity and related topics to be held at the OGF meeting next week. It is clear to me that recent improvements to the availability and technology for authentication, authorization and attribute transmission will make many modes of access to grid resources possible with appropriate security that up to now have been either impossible or confined to limited implementation.
For the moment, I would like to suggest that a revision of the HPC profile propose that "only GSI or equivalently secure architectures be
used for direct access to HPC resources" and that the document be revised specifically to discourage the direct access by users to highly capable computational and to secure storage resources by username/password mechanisms. In my own project, we use GSI-OpenSSH via grid-mapfiles. I have been able to confirm that current implementations of GSI-OpenSSH are capable of interoperating with more general callout-based systems, including attribute-based AuthZ systems, without modification. Therefore it is not necessary for users to have username/password access if direct login is needed on an HPC system.
As a further enhancement to the document and to the profile, I feel it
would be useful to describe architectures for pure-computational (i.e., batch-only access), for pure-login (i.e., front-end and submission access), pure-storage (i.e., stage-in/stage-out and related data handling) and for the interesting use case of "managed fork" (i.e., interactive but sand-boxed grid access) systems. I believe these changes would result in an improved HPC profile that would be of better total usability within the HPC community. This document is NOT attached, instead your original one is for discussion, but I believe can be worked out in the context of discussions to be held at OGF-19 next week.
Sorry for being (apparently but not really) strident, but I believe the above reflects current best practices better than recommending username/password support for direct login to HPC systems. I would not personally be able to support the current draft as written.
Thanks and best wishes, Alan
On Jan 18, 2007, at 2:16 PM, Andrew Grimshaw wrote:
All,
On this mornings call I volunteered to see what was up with the HPC profile working group with respect to authentication. Recall that we
need some sort of authentication story in the short run or we cannot put together any form or realistic, cross-organizational, compute grids with BES, or for that matter data grids using RNS/ByteIO.
Attached is a short white paper from the HPC Profile WG (or maybe just the three authors). It is BES-specific, but I think the ideas may be generalized to a broader set of OGSA services. I think we should consider it, or something like it.
Note that it does NOT deal with the ultimate authentication and delegation problem that we will face. Rather, I personally (speaking only for myself, and not even the people in my research group) think that this sort of solution is a stop gap that we can use for awhile, and that we will ultimately deprecate in favor of whatever comes out of the OGSA-Authentication WG.
So, for your reading pleasure - and with my thanks to Marty for giving me a copy.
A
Andrew Grimshaw
Professor of Computer Science
University of Virginia
434-982-2204
grimshaw@cs.virginia.edu
--
ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
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
[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
(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
Hi Blair Interestingly you say very little about their Authz requirements or why, for example, GFD.66 cannot meet them. Do you have more info about this? thanks David Blair Dillaway wrote:
(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 -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
Hi David, First, I presume that "their Authz requirements" refers to the HPC Profile group, yes? If so, then I'll speak up. AuthZ is out of scope. AuthN *is* in scope. Note that I am personally very supportive of the GFD.66 effort -- after all, my group is one of the few groups who have actually implemented it! (in our .NET code). I could see this GFD.66 coming into play as an Extension if the demand warrants it. Perhaps some of this more philosophical discussion should take place next week in North Carolina (OGF 19)? It's difficult to sufficiently explain oneself in email at times. -- Marty -----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of David Chadwick Sent: Monday, January 22, 2007 4:14 PM To: Blair Dillaway Cc: OGSA Authentication WG BoF; Jim Basney; ogsa-wg@gridforum.org Subject: Re: [ogsa-wg] [ogsa-authn-bof] Authentication in OGSA Hi Blair Interestingly you say very little about their Authz requirements or why, for example, GFD.66 cannot meet them. Do you have more info about this? thanks David Blair Dillaway wrote:
(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 -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
(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
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
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
David, Marty gave the reason why authZ isn't mentioned. But, I'll interpret your comment more generally as to why SAML for authN isn't an option. We had a discussion about whether to include authN profiles for other token types, SAML and Kerberos in particular since there are already SOAP Message Security profiles. They weren't included based on two considerations: 1)there was a strong desire to keep the number of options to a minimum to reduce implementation/testing requirements as well as to make interoperability more certain 2) X.509 and/or username-password are believed to be the most widely deployed intra-org authN mechanisms with Kerberos and SAML less likely to be present. We can certainly discuss this at OGF19 if people think inclusion of SAML or Kerberos options would be valuable additions. Regards, Blair -----Original Message----- From: Marty Humphrey [mailto:humphrey@cs.virginia.edu] Sent: Monday, January 22, 2007 1:24 PM To: 'David Chadwick'; Blair Dillaway Cc: 'OGSA Authentication WG BoF'; 'Jim Basney'; ogsa-wg@gridforum.org Subject: RE: [ogsa-wg] [ogsa-authn-bof] Authentication in OGSA Hi David, First, I presume that "their Authz requirements" refers to the HPC Profile group, yes? If so, then I'll speak up. AuthZ is out of scope. AuthN *is* in scope. Note that I am personally very supportive of the GFD.66 effort -- after all, my group is one of the few groups who have actually implemented it! (in our .NET code). I could see this GFD.66 coming into play as an Extension if the demand warrants it. Perhaps some of this more philosophical discussion should take place next week in North Carolina (OGF 19)? It's difficult to sufficiently explain oneself in email at times. -- Marty -----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of David Chadwick Sent: Monday, January 22, 2007 4:14 PM To: Blair Dillaway Cc: OGSA Authentication WG BoF; Jim Basney; ogsa-wg@gridforum.org Subject: Re: [ogsa-wg] [ogsa-authn-bof] Authentication in OGSA Hi Blair Interestingly you say very little about their Authz requirements or why, for example, GFD.66 cannot meet them. Do you have more info about this? thanks David Blair Dillaway wrote: the proposed 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 -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 ***************************************************************** -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Hi Blair Blair Dillaway wrote:
David,
Marty gave the reason why authZ isn't mentioned. But, I'll interpret your comment more generally as to why SAML for authN isn't an option.
I wasnt actually raising this as an issue..
We had a discussion about whether to include authN profiles for other token types, SAML and Kerberos in particular since there are already SOAP Message Security profiles. They weren't included based on two considerations: 1)there was a strong desire to keep the number of options to a minimum to reduce implementation/testing requirements as well as to make interoperability more certain
sensible. The more options you have, the more a server needs to implement in order to cater for all clients.
2) X.509 and/or username-password are believed to be the most widely deployed intra-org authN mechanisms with Kerberos and SAML less likely to be present.
The only way you will find out if your beliefs are true or not is to perform some sort of census with the users to find out what they are really using. Has anyone tried this or not? regards David
We can certainly discuss this at OGF19 if people think inclusion of SAML or Kerberos options would be valuable additions.
Regards, Blair
-----Original Message----- From: Marty Humphrey [mailto:humphrey@cs.virginia.edu] Sent: Monday, January 22, 2007 1:24 PM To: 'David Chadwick'; Blair Dillaway Cc: 'OGSA Authentication WG BoF'; 'Jim Basney'; ogsa-wg@gridforum.org Subject: RE: [ogsa-wg] [ogsa-authn-bof] Authentication in OGSA
Hi David,
First, I presume that "their Authz requirements" refers to the HPC Profile group, yes?
If so, then I'll speak up. AuthZ is out of scope. AuthN *is* in scope.
Note that I am personally very supportive of the GFD.66 effort -- after all, my group is one of the few groups who have actually implemented it! (in our .NET code). I could see this GFD.66 coming into play as an Extension if the demand warrants it.
Perhaps some of this more philosophical discussion should take place next week in North Carolina (OGF 19)? It's difficult to sufficiently explain oneself in email at times.
-- Marty
-----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of David Chadwick Sent: Monday, January 22, 2007 4:14 PM To: Blair Dillaway Cc: OGSA Authentication WG BoF; Jim Basney; ogsa-wg@gridforum.org Subject: Re: [ogsa-wg] [ogsa-authn-bof] Authentication in OGSA
Hi Blair
Interestingly you say very little about their Authz requirements or why,
for example, GFD.66 cannot meet them. Do you have more info about this?
thanks
David
(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
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
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
Blair Dillaway wrote: the proposed 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 -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
Hi Marty Marty Humphrey wrote:
Hi David,
First, I presume that "their Authz requirements" refers to the HPC Profile group, yes?
yes, correct
If so, then I'll speak up. AuthZ is out of scope. AuthN *is* in scope.
Actually Authz cannot be out of scope of a true security profile, otherwise anyone who was authenticated could do anything to any resource. And clearly this is not allowed. So what you probably mean is either that the Security Profile is not a security profile but rather an Authn profile only, or authz is part of the security profile but is not standardised and each system is free to implement its own authz mechanism to control who can do what.
Note that I am personally very supportive of the GFD.66 effort -- after all, my group is one of the few groups who have actually implemented it! (in our .NET code). I could see this GFD.66 coming into play as an Extension if the demand warrants it.
Perhaps some of this more philosophical discussion should take place next week in North Carolina (OGF 19)? It's difficult to sufficiently explain oneself in email at times.
I agree. See you then David
-- Marty
-----Original Message----- From: ogsa-wg-bounces@ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of David Chadwick Sent: Monday, January 22, 2007 4:14 PM To: Blair Dillaway Cc: OGSA Authentication WG BoF; Jim Basney; ogsa-wg@gridforum.org Subject: Re: [ogsa-wg] [ogsa-authn-bof] Authentication in OGSA
Hi Blair
Interestingly you say very little about their Authz requirements or why, for example, GFD.66 cannot meet them. Do you have more info about this?
thanks
David
Blair Dillaway wrote:
(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 -- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- ***************************************************************** David W. Chadwick, BSc PhD Professor of Information Systems Security The Computing Laboratory, University of Kent, Canterbury, CT2 7NF Skype Name: davidwchadwick Tel: +44 1227 82 3221 Fax +44 1227 762 811 Mobile: +44 77 96 44 7184 Email: D.W.Chadwick@kent.ac.uk Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html Research Web site: http://sec.cs.kent.ac.uk Entrust key validation string: MLJ9-DU5T-HV8J PGP Key ID is 0xBC238DE5 *****************************************************************
As a correction, let me point out that the OGSA-AuthN BOF is intended to provide a process for moving forward from existing efforts in AuthN, and does not have the role that you imply here. The basic features of GSI and related technologies are well documented and clearly spelled out in existing literature. I was, and am, focusing on grid (specifically grid services) authentication here. Alan On Jan 22, 2007, at 1:32 PM, Steven Newhouse wrote:
'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.
Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
Alan, We have had discussions in the HPC Profile WG on this topic, and we believe that the approach taken by the HPC Profile WG (reflected in the "Security Considerations for the HPC Profile" doc you reference) is the correct one to appropriately meet the requirements of the use-cases that we have identified. I admire the goals of your larger effort, but I believe that our HPC Profile WG needs to remain focused on putting the final touches on the HPC Basic Profile so that it can enter the OGF document/standardization process. I believe that our WG has done an excellent job of creating a modular, evolutionary design that properly balances more "long-term" concerns against the constraints of existing and not-too-far-off-in-the-future commercial and open-source tooling. I also believe the current drafts in the HPC Profile WG reflect a broad balance of current and future academic and commercial interests. You'll note that in the HPC Profile, there are essentially TWO options for client-side authentication: X.509 and username/password. Clearly organizations can mandate the X.509 approach if they desire, but entirely eliminating username/password authentication as an option would further unnecessarily separate "The Grid folks" from mainstream commercial approaches and efforts. Good luck with your WG efforts - we are certainly open to utilizing the results of your efforts in a subsequent revision of the HPC Profile. Given our HPC Profile's time constraints and deadlines, I believe that we need to stick with our current approach and drafts. Regards, Marty -----Original Message----- From: security-area-bounces@ogf.org [mailto:security-area-bounces@ogf.org] On Behalf Of Alan Sill Sent: Monday, January 22, 2007 3:19 AM To: Andrew Grimshaw Cc: OGSA Authentication WG BoF; security-area@ogf.org; ogsa-wg@gridforum.org Subject: Re: [SECURITY-AREA] [ogsa-wg] Authentication in OGSA Hi Andrew and the OGSA-WG, I apologize for missing the meeting last Thursday on this topic. We have a machine full of new cluster and grid equipment, and I have been fully occupied commissioning and configuring it. I am afraid that I differ rather strongly with the direction being taken with regard to the HPC profile at this stage. My view is strongly that simple username/password login, even SSL secured, is quite demonstrably insufficiently secure to deploy as a model for authentication and access to high performance computing. I disagree fairly strongly that any sort of stop-gap of this nature should be written into the HPC profile, distributed or promoted at this time. I have an excuse for having taken so long to reply on this topic. It was necessary for me to investigate as thoroughly as possible the current state of deployment of GSI-secured alternatives to username/ password login and to do so in a way that would allow me to give a credible response to all of you regarding the state of the art on this topic. At this point I am assured and feel sufficiently confident to proceed, either at OGF-19 or before, with Andrew, Marty, and whoever else would like to participate on a revision of the HPC profile that would cover more secure basic access to high performance cluster and storage systems based on GSIOpenSSH and similar software that uses either GT4 or an equivalent callout. We are writing standards, not implementations, but I wished to be sure that the state of the art on existing implementations would be consistent with making this recommendation. It is essential from my point of view to promote secure access to HPC resources. As the bulk of the compromise attacks that have been successful over the past 2 to 3 years on HPC resources has been through discovery and reuse of username/password combinations from ordinary users (at least as I read the recent record), I think that now is not the right time to propose backing off from the use of strong cryptographic methods to use HPC resources in grid settings. The use of strong cryptography does not have to be limited to X.509 "pure classic" PKI, and I look forward to an active discussion on federated identity and related topics to be held at the OGF meeting next week. It is clear to me that recent improvements to the availability and technology for authentication, authorization and attribute transmission will make many modes of access to grid resources possible with appropriate security that up to now have been either impossible or confined to limited implementation. For the moment, I would like to suggest that a revision of the HPC profile propose that "only GSI or equivalently secure architectures be used for direct access to HPC resources" and that the document be revised specifically to discourage the direct access by users to highly capable computational and to secure storage resources by username/password mechanisms. In my own project, we use GSI-OpenSSH via grid-mapfiles. I have been able to confirm that current implementations of GSI-OpenSSH are capable of interoperating with more general callout-based systems, including attribute-based AuthZ systems, without modification. Therefore it is not necessary for users to have username/password access if direct login is needed on an HPC system. As a further enhancement to the document and to the profile, I feel it would be useful to describe architectures for pure-computational (i.e., batch-only access), for pure-login (i.e., front-end and submission access), pure-storage (i.e., stage-in/stage-out and related data handling) and for the interesting use case of "managed fork" (i.e., interactive but sand-boxed grid access) systems. I believe these changes would result in an improved HPC profile that would be of better total usability within the HPC community. This document is NOT attached, instead your original one is for discussion, but I believe can be worked out in the context of discussions to be held at OGF-19 next week. Sorry for being (apparently but not really) strident, but I believe the above reflects current best practices better than recommending username/password support for direct login to HPC systems. I would not personally be able to support the current draft as written. Thanks and best wishes, Alan On Jan 18, 2007, at 2:16 PM, Andrew Grimshaw wrote:
All,
On this mornings call I volunteered to see what was up with the HPC profile working group with respect to authentication. Recall that we need some sort of authentication story in the short run or we cannot put together any form or realistic, cross-organizational, compute grids with BES, or for that matter data grids using RNS/ ByteIO.
Attached is a short white paper from the HPC Profile WG (or maybe just the three authors). It is BES-specific, but I think the ideas may be generalized to a broader set of OGSA services. I think we should consider it, or something like it.
Note that it does NOT deal with the ultimate authentication and delegation problem that we will face. Rather, I personally (speaking only for myself, and not even the people in my research group) think that this sort of solution is a stop gap that we can use for awhile, and that we will ultimately deprecate in favor of whatever comes out of the OGSA-Authentication WG.
So, for your reading pleasure - and with my thanks to Marty for giving me a copy.
A
Andrew Grimshaw
Professor of Computer Science
University of Virginia
434-982-2204
grimshaw@cs.virginia.edu
--
ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Hi Marty, Thank you for your response. I look forward to a healthy discussion on these and related topics in the future. Please note that my remarks were and are confined to the use case of grid services access to high performance computing clusters and related highly vulnerable resources, and should not be taken as a condemnation of username/password access in general. I am excited and hopeful about the range of choices for delivery of grid services to users across a range of needs for levels of assurance. I strongly believe that the path that has been taken up to now for delivery of HPC resources through grid methods through X. 509 and related technologies has been wise, and that it is unwise to write a profile for HPC that encourages the use of unadorned username/ access methods. We have seen compromises through these means in several cases. I think the path forward for this use case is in fact towards a higher level of assurance of identity than is possible with simple username/password access, and strongly discourage inclusion of this method in the HPC profile, at least for direct logon to shell resources. While this may be the practice for non-grid services and may be suitable for delivery of access to other vehicles, it is NOT the practice for current grid-enabled logons at present and I believe the HPC group is off track in encouraging it. This is, however, just my opinion. With best wishes, Alan On Jan 22, 2007, at 7:11 AM, Marty Humphrey wrote:
Alan,
We have had discussions in the HPC Profile WG on this topic, and we believe that the approach taken by the HPC Profile WG (reflected in the "Security Considerations for the HPC Profile" doc you reference) is the correct one to appropriately meet the requirements of the use-cases that we have identified. I admire the goals of your larger effort, but I believe that our HPC Profile WG needs to remain focused on putting the final touches on the HPC Basic Profile so that it can enter the OGF document/ standardization process.
I believe that our WG has done an excellent job of creating a modular, evolutionary design that properly balances more "long-term" concerns against the constraints of existing and not-too-far-off-in-the-future commercial and open-source tooling. I also believe the current drafts in the HPC Profile WG reflect a broad balance of current and future academic and commercial interests.
You'll note that in the HPC Profile, there are essentially TWO options for client-side authentication: X.509 and username/password. Clearly organizations can mandate the X.509 approach if they desire, but entirely eliminating username/password authentication as an option would further unnecessarily separate "The Grid folks" from mainstream commercial approaches and efforts.
Good luck with your WG efforts - we are certainly open to utilizing the results of your efforts in a subsequent revision of the HPC Profile. Given our HPC Profile's time constraints and deadlines, I believe that we need to stick with our current approach and drafts.
Regards, Marty
-----Original Message----- From: security-area-bounces@ogf.org [mailto:security-area- bounces@ogf.org] On Behalf Of Alan Sill Sent: Monday, January 22, 2007 3:19 AM To: Andrew Grimshaw Cc: OGSA Authentication WG BoF; security-area@ogf.org; ogsa- wg@gridforum.org Subject: Re: [SECURITY-AREA] [ogsa-wg] Authentication in OGSA
Hi Andrew and the OGSA-WG,
I apologize for missing the meeting last Thursday on this topic. We have a machine full of new cluster and grid equipment, and I have been fully occupied commissioning and configuring it.
I am afraid that I differ rather strongly with the direction being taken with regard to the HPC profile at this stage. My view is strongly that simple username/password login, even SSL secured, is quite demonstrably insufficiently secure to deploy as a model for authentication and access to high performance computing. I disagree fairly strongly that any sort of stop-gap of this nature should be written into the HPC profile, distributed or promoted at this time.
I have an excuse for having taken so long to reply on this topic. It was necessary for me to investigate as thoroughly as possible the current state of deployment of GSI-secured alternatives to username/ password login and to do so in a way that would allow me to give a credible response to all of you regarding the state of the art on this topic.
At this point I am assured and feel sufficiently confident to proceed, either at OGF-19 or before, with Andrew, Marty, and whoever else would like to participate on a revision of the HPC profile that would cover more secure basic access to high performance cluster and storage systems based on GSIOpenSSH and similar software that uses either GT4 or an equivalent callout. We are writing standards, not implementations, but I wished to be sure that the state of the art on existing implementations would be consistent with making this recommendation.
It is essential from my point of view to promote secure access to HPC resources. As the bulk of the compromise attacks that have been successful over the past 2 to 3 years on HPC resources has been through discovery and reuse of username/password combinations from ordinary users (at least as I read the recent record), I think that now is not the right time to propose backing off from the use of strong cryptographic methods to use HPC resources in grid settings. The use of strong cryptography does not have to be limited to X.509 "pure classic" PKI, and I look forward to an active discussion on federated identity and related topics to be held at the OGF meeting next week. It is clear to me that recent improvements to the availability and technology for authentication, authorization and attribute transmission will make many modes of access to grid resources possible with appropriate security that up to now have been either impossible or confined to limited implementation.
For the moment, I would like to suggest that a revision of the HPC profile propose that "only GSI or equivalently secure architectures be used for direct access to HPC resources" and that the document be revised specifically to discourage the direct access by users to highly capable computational and to secure storage resources by username/password mechanisms. In my own project, we use GSI-OpenSSH via grid- mapfiles. I have been able to confirm that current implementations of GSI- OpenSSH are capable of interoperating with more general callout-based systems, including attribute-based AuthZ systems, without modification. Therefore it is not necessary for users to have username/password access if direct login is needed on an HPC system.
As a further enhancement to the document and to the profile, I feel it would be useful to describe architectures for pure-computational (i.e., batch-only access), for pure-login (i.e., front-end and submission access), pure-storage (i.e., stage-in/stage-out and related data handling) and for the interesting use case of "managed fork" (i.e., interactive but sand-boxed grid access) systems. I believe these changes would result in an improved HPC profile that would be of better total usability within the HPC community. This document is NOT attached, instead your original one is for discussion, but I believe can be worked out in the context of discussions to be held at OGF-19 next week.
Sorry for being (apparently but not really) strident, but I believe the above reflects current best practices better than recommending username/password support for direct login to HPC systems. I would not personally be able to support the current draft as written.
Thanks and best wishes, Alan
On Jan 18, 2007, at 2:16 PM, Andrew Grimshaw wrote:
All,
On this mornings call I volunteered to see what was up with the HPC profile working group with respect to authentication. Recall that we need some sort of authentication story in the short run or we cannot put together any form or realistic, cross-organizational, compute grids with BES, or for that matter data grids using RNS/ ByteIO.
Attached is a short white paper from the HPC Profile WG (or maybe just the three authors). It is BES-specific, but I think the ideas may be generalized to a broader set of OGSA services. I think we should consider it, or something like it.
Note that it does NOT deal with the ultimate authentication and delegation problem that we will face. Rather, I personally (speaking only for myself, and not even the people in my research group) think that this sort of solution is a stop gap that we can use for awhile, and that we will ultimately deprecate in favor of whatever comes out of the OGSA-Authentication WG.
So, for your reading pleasure - and with my thanks to Marty for giving me a copy.
A
Andrew Grimshaw
Professor of Computer Science
University of Virginia
434-982-2204
grimshaw@cs.virginia.edu
--
ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
Alan Sill, Ph.D TIGRE Senior Scientist, High Performance Computing Center Adjunct Professor of Physics TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill@ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================
participants (8)
-
Alan Sill -
Andrew Grimshaw -
Blair Dillaway -
David Chadwick -
Hiro Kishimoto -
Marty Humphrey -
Steven Newhouse -
Von Welch