[ogsa-wg] [ogsa-authn-bof] Authentication in OGSA

Mon Jan 22 12:13:45 CST 2007

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 at 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 at ogf.org; ogsa-wg at 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 at ogf.org
> [mailto:ogsa-authn-bof-bounces at 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 at ogf.org;
> ogsa-wg at 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 at cs.virginia.edu
>>>
>>>  --
>>>
>>>   ogsa-wg mailing list
>>>   ogsa-wg at 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 at ttu.edu   ph. 806-742-4350  fax 806-742-4358  :
====================================================================