- security-area - lists.ogf.org

Levels of Assurance RG BoF
by David Groep 20 Feb '07

20 Feb '07

Dear all, A well-attended "Levels of Assurance" BoF session was held during OGF 19 last month. We are now starting the raod towards the formation of a OGF Research Group (proposed) to address this topic. The focus is around topics such as: 1) "Overview of current LoA criteria and the relation to the risk analysis by relying parties in an e-Science context". What is it that relying parties really need to know about an identity assertion, what qualities do they require, and which attributes do they 'need to know' about an assertion provider in order to decide on trust in the assertion? 2) "gap analysis of reference definitions by current LoA standards and the requirements of grid and e-Science use cases for identity assertions". Current LoA definitions are intended for direct validation by a service provider and are mostly based on planned government and defence uses and on client-server electronic transactions. This work will identify the gaps between these definitions and the potential use of LoA in the grid context. Specific use cases will be gathered as part of this work. You are kindly invited to join, contribute and subscribe to the RG BoFs mailing list via http://www.ogf.org/mailman/listinfo/loa-bof Best regards, David Groep. -- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL ** -- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **

1 0

Re: [SECURITY-AREA] [ogsa-wg] [ogsa-authn-bof] Authentication in OGSA
by Alan Sill 22 Jan '07

22 Jan '07

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(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

1 0

Re: [SECURITY-AREA] [ogsa-authn-bof] [ogsa-wg] Authentication in OGSA
by Blair Dillaway 22 Jan '07

22 Jan '07

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(a)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(a)ogf.org; ogsa-wg(a)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(a)cs.virginia.edu >> >> -- >> >> ogsa-wg mailing list >> ogsa-wg(a)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(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : > ==================================================================== > > > > ------------------------------------------------------------------------ > > -- > ogsa-wg mailing list > ogsa-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-wg _______________________________________________ ogsa-authn-bof mailing list ogsa-authn-bof(a)ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authn-bof

2 2

Re: [SECURITY-AREA] [ogsa-wg] Authentication in OGSA
by Alan Sill 22 Jan '07

22 Jan '07

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(a)cs.virginia.edu > > -- > > ogsa-wg mailing list > ogsa-wg(a)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(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ====================================================================

2 2

TC-RG: replacement mailing list
by Andrew Martin 14 Dec '06

14 Dec '06

Hi everyone, TC-RG is being shut down. There has been some interest shown in keeping alive a discussion about Trusted Computing Technologies and Grid, however. Therefore, I have established a new mailing list. Subscriptions will not automatically be copied across to the new list: please re-join. If you would like to join the list, please send an email to jiscmail(a)jiscmail.ac.uk containing the single line JOIN TC-GRID-RG firstname lastname We are hoping to have a face-to-face meeting at Royal Holloway in London, sometime early in the New Year. Best regards: Merry Christmas and Happy New Year! Andrew

1 0

TC RG Proposed Shutdown
by Blair Dillaway 07 Dec '06

07 Dec '06

Dear Security Area Participants: We have recently completed a review of the security area groups. Based on the results, we propose to disband the Trusted Computing Research Group (TC RG). We have noted that during the past year: - There has been no substantive progress on the chartered deliverables - There have been no active discussions on the mailing list or regular conferences calls - Attendance at the TC RG sessions has been minimal We have queried the chairpersons about their continued interest and thoughts on re-invigorating this activity. Their responses indicate: - They are unable to commit to completing the existing draft use-case document - They do not have a proposal for re-chartering the group to engage a critical mass of participants We would appreciate hearing from anyone who is willing to commit to completing the chartered deliverables and participating in possible follow-on work. Unless a sufficient number of committed participants come forward in the next 2-3 weeks, we will start the process of shutting down the group. Regards, Blair Dillaway and David Groep, Security ADs

1 1

OGF Security Area Update December 2006
by David Groep 04 Dec '06

04 Dec '06

Dear all, Over the past few months, several new activities have started in the OGF Security Area. With this Update, we would like to inform you about these activities and at the same time foster coherency in the security area. We hope you find this update useful and welcome any comments you have on this kind of communication, and of course on any grid security related activities. Note also the OGF 19 early registration deadline of December 8 (Friday). We hope that, with the activities listed below, the OGF 19 program will be interesting and packed with security-related activities. Best regards, the Security ADs Blair Dillaway and David Groep. In this update: - NEW: OGSA-AuthN Charter BoF to be held at OGF19 - NEW: Activity discussion on Levels of Assurance issues - OGSA Basic Security Profile Core and Security Channel - OGSA-AuthZ-WG re-chartered - Firewall Issues RG documents and group directions - CAOPS Document progress and sessions These updates will usually be sent to the <security-area at ogf.org> list, to which you can subscribe via http://mailman.ogf.org/ OGSA-AuthN Charter BoF ---------------------- The OGSA-AuthN group is currently being bootstrapped to look at technologies and mechanisms for authentication in the OGSA context. The groups focus will be on the drafting the roadmap for OGSA authentication technologies, documentation of existing authentication community practices, and look at the issues surrounding AuthN delegation. The group and BoF is being organised and animated by Alan Sill of Texas Tech. Discussions on the exact scope of the group are currently ongoing on the BoF mailing list, and a BoF session will be held during OGF19. These discussions should result in a charter proposal being brought to the community at the BoF. It is explicitly a part of the charter for this group to work in a symmetrical manner with any OGSA-AuthZ work that may be needed for consistency in grid services. For more information Draft charter: http://www.ggf.org/gf/group_info/charter.php?review&group=OGSA-AuthN-WG Mailing list: ogsa-authn-bof(a)ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authn-bof/ Topical BoF on Levels of Assurance (LoAs) ----------------------------------------- Ideas around "Levels of Assurance" have been receiving more and more attention, with the advance of federations and Authentication and Authorization infrastructures. "LoA is defined as the strength of authentication required for a service provider to be assured that a resource access is only granted to users whose identities have been verified. It reflects the degree of confidence in an authentication process used to establish the identity of an entity (an individual or a software component) to whom the credential was issued, and the degree of confidence that the entity using the credential is indeed the entity that the credential was issued to." Ning Zhang of Manchester University has taken the initiative to bring up the discussion on this activity in the OGF context. Examples of questions that this activity could address are: - What are the existing definitions of LoA suited to Grid or VO environment? - How to apply LoA to safeguard Grid services/resources? - Are some onerous registration requirements or special condition stipulations due to perceived inadequacies in the strength of authentication? - Are there any limitations in terms of user accessibility, scalability and interoperability? The activity can include discussion on how operational procedures affect LoA, how the various parameters and factors influence the overall LoA value in grid/VO environments, and come up with recommendations on how these factors can be taken into account. The purpose here is to consult, and to seek comments and feedbacks from, the communities concerned (including service providers, from e-Science, e-Business and e-Gov) on their views on the definition and applications of LoA in achieving fine-grained access control. Everyone interested in such an activity is extremely welcome to attend this activity BoF session. If there is sufficient interest within OGF, the BoF can also discuss how the activity is best embedded in the OGF organisation; it is not necessarily the aim of this BoF to result in a new research or working group. More information: Security Area Wiki: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.sec/wiki/LoAInitia… Document "e-Infrastructure Security: Levels of Assurance" https://forge.gridforum.org/sf/sfmain/do/downloadAttachment/projects.sec/wi… Discussion forum: https://forge.gridforum.org/sf/discussion/do/listTopics/projects.sec/discus… OGSA Basic Security Profile Core and Security Channel documents --------------------------------------------------------------- The updated version of the OGSA Basic Security Profile 1.0 - Core has entered WG final call and is available on GridForge: https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-wg/… The OGSA Security Profile 1.0 - Secure Channel document draft, discussing how to establish a secure channel in the OGSA context, has been revised and is now available at https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-wg/… OGSA-AuthZ-WG re-chartered ------------------------- The OGSA-AuthZ Working Group has been rechartered and now addresses more advanced features that are required, such as obligations, decisions based on action parameters, policy management, dynamic delegation of authority, attribute schema exchanges etc. The new charter is available from http://www.ggf.org/gf/group_info/charter.php?review&group=OGSA-AuthZ-WG Firewall Issues overview document published ------------------------------------------- This "Firewall Issues Overview" information track document by Ralph Niederberger et al., has been published as GFD-I.083. You can download it here: http://www.ggf.org/gf/docs/?final The middlebox technology overview and evaluation document is coming up next, and new documents are being considered on the mailing list More information: Charter: http://www.ggf.org/gf/group_info/charter.php?review&group=FI-RG Mailing list: fi-rg(a)ogf.org http://www.ogf.org/mailman/listinfo/fi-rg/ CAOPS Documents and sessions ---------------------------- CAOPS will hold two sessions during the upcoming OGF 19 event, of which one is traditionally dedicated to the International Grid Trust Federation (IGTF). Current draft document for example include the Grid Certificate Profile, a comprehensive collection of the community knowledge on what works and does not work in an interoperable PKI geared to currently running grids. More information: Charter: http://www.ggf.org/gf/group_info/charter.php?review&group=CAOPS-WG International Grid Trust Federation http://www.gridpma.org/ Grid Certificate Profile: https://forge.gridforum.org/sf/go/doc13741 (PDF) https://forge.gridforum.org/sf/go/doc13742 (MS Word) -- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **

1 0

Re: [SECURITY-AREA] [TC-RG] TC RG Proposed Shutdown
by wenbo.mao＠hp.com 22 Nov '06

22 Nov '06

Dear All, While as a group leader I do feel responsible for not having been successful to generate a high interest in this work, we have nevertheless been working out the technicalities through other forums, and are not insuccessful in that regard. A Daonity demo system was released on November 17th in the Daonity Homepage: http://www.hpl.hp.com/personal/Wenbo_Mao/daonity/daonity.html (binary executable and source), where one may also find sufficient amount of supporting material. If at present we cannot convince the OGF community the usefulness of Trusted Computing for grid security (not your fault), we then agree to shut this group down. In the mean time, we shall continue working on the technicalities. For the interested, please keep an eye on the above URL. Thank you! Best regards, Wenbo Mao > Dear Security Area Participants: > > > > We have recently completed a review of the security area groups. Based > on the results, we propose to disband the Trusted Computing Research > Group (TC RG). We have noted that during the past year: > > - There has been no substantive progress on the chartered deliverables > > - There have been no active discussions on the mailing list or regular > conferences calls > > - Attendance at the TC RG sessions has been minimal > > > > We have queried the chairpersons about their continued interest and > thoughts on re-invigorating this activity. Their responses indicate: > > - They are unable to commit to completing the existing draft use-case > document > > - They do not have a proposal for re-chartering the group to engage a > critical mass of participants > > > > We would appreciate hearing from anyone who is willing to commit to > completing the chartered deliverables and participating in possible > follow-on work. Unless a sufficient number of committed participants > come forward in the next 2-3 weeks, we will start the process of > shutting down the group. > > > > Regards, > > Blair Dillaway and David Groep, Security ADs > > > > -- > tc-rg mailing list > tc-rg(a)ogf.org > http://www.ogf.org/mailman/listinfo/tc-rg

1 0

Topical OGF Levels of Assurance (LoAs) BoF and activity initiative
by David Groep 15 Nov '06

15 Nov '06

Dear all, The OGF Security Area would like to draw your attention to an initiative addressing topics around the concept of Levels of Assurance. We know or expect that at least quite a few of you are interested in this topic, and thus are likely to either participate and have an opinion on this... An initial description of the activity and possible directions are described below. Please note that this will be a topical activity BoF, and is not aimed to be a charter BoF or to necessarily create a new group. If there is sufficient momentum to address this topic (also) in the OGF context, we can subsequently discuss the organisational embedding in an existing or new group. So, if you are interested, please participate via the security area mailing list or the gforge Wiki and forum, whose URLs are listed below. A BoF session to discuss this activity will be organised during OGF19 (to be held in North Carolina on January 29 - February 2, 2007). You are very warmly invited to attend this event, which will be full of new activities in the security area. Best regards, Blair Dillaway and David Groep, (OGF Security ADs) Topical BoF on Levels of Assurance (LoAs) ----------------------------------------- Ideas around "Levels of Assurance" have been receiving more and more attention, with the advance of federations and Authentication and Authorization infrastructures. "LoA is defined as the strength of authentication required for a service provider to be assured that a resource access is only granted to users whose identities have been verified. It reflects the degree of confidence in an authentication process used to establish the identity of an entity (an individual or a software component) to whom the credential was issued, and the degree of confidence that the entity using the credential is indeed the entity that the credential was issued to." Ning Zhang of Manchester University has taken the initiative to bring up the discussion on this activity in the OGF context. Examples of questions that this activity could address are: - What are the existing definitions of LoA suited to Grid or VO environment? - How to apply LoA to safeguard Grid services/resources? - Are some onerous registration requirements or special condition stipulations due to perceived inadequacies in the strength of authentication? - Are there any limitations in terms of user accessibility, scalability and interoperability? The activity can include discussion on how operational procedures affect LoA, how the various parameters and factors influence the overall LoA value in grid/VO environments, and come up with recommendations on how these factors can be taken into account. The purpose here is to consult, and to seek comments and feedbacks from, the communities concerned (including service providers, from e-Science, e-Business and e-Gov) on their views on the definition and applications of LoA in achieving fine-grained access control. Everyone interested in such an activity is extremely welcome to attend this activity BoF session. If there is sufficient interest within OGF, the BoF can also discuss how the activity is best embedded in the OGF organisation; it is not necessarily the aim of this BoF to result in a new research or working group. More information: Security Area Wiki: https://forge.gridforum.org/sf/wiki/do/viewPage/projects.sec/wiki/LoAInitia… Document "e-Infrastructure Security: Levels of Assurance" https://forge.gridforum.org/sf/sfmain/do/downloadAttachment/projects.sec/wi… Discussion forum: https://forge.gridforum.org/sf/discussion/do/listTopics/projects.sec/discus… -- David Groep ** National Institute for Nuclear and High Energy Physics, PDP/Grid group ** ** Room: H1.56 Phone: +31 20 5922179, PObox 41882, NL-1009DB Amsterdam NL **

1 0

List invitation: OGSA-AuthN-BoF for grid services authentication issues
by Alan Sill 08 Nov '06

08 Nov '06

This is the last in a series of messages intended to announce a requested Birds-of-a-Feather session (BoF) at the Open Grid Forum OGF-19 meeting for discussion of Open Grid Services Architecture Authentication topics and activities. The list and its associated BoF are intended to carry out the steps for formation of an OGSA- AuthN work group. This message is being sent out widely to call your attention to the existence of a mailing list specific to this purpose. You may subscribe to the ogsa-authn-bof(a)ogf.org mailing list by sending a message to me or to David Groep <davidg(a)nikhef.nl> , or by visiting the following page: http://www.ogf.org/mailman/listinfo/ogsa-authn-bof Your participation is appreciated. This announcement will be sent to several relevant lists and people to extend the invitation as broadly as possible, but subsequent communication about the BoF will proceed through the above list. Subscription to the above list will be your method to ensure involvement in this process. Best, Alan Sill, Ph.D TIGRE Senior Scientist High Performance Computing Center TTU ==================================================================== : Alan Sill, Texas Tech University Office: Admin 233, MS 4-1167 : : e-mail: Alan.Sill(a)ttu.edu ph. 806-742-4350 fax 806-742-4358 : ==================================================================== -- ogsa-authz-wg mailing list ogsa-authz-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/ogsa-authz-wg

1 0