- security-area - lists.ogf.org

RE: Authority Recognition document now in public comment
by Olle Mulmo 31 Jan '05

31 Jan '05

PS. You are of course welcome and encouraged to comment on the other documents listed on the URL below as well. /O -----Original Message----- From: Olle Mulmo [mailto:mulmo@pdc.kth.se] Sent: Monday, January 31, 2005 11:52 To: 'security-area(a)ggf.org'; 'arrg-rg(a)ggf.org' Subject: Authority Recognition document now in public comment Dear all, The outcome of the work accomplished in the Authority Recognition Research Group has entered a Public Comment period until February 24, 2005. Please visit http://www.ggf.org/Public_Comment_Docs/Public_Comment_Documents.htm and document your consent or disagreement with the document using the "Make Comments" form. You may be anonymous. Note that we also recommend that the authors and group members themselves to publicly provide a comment during this period that to an effect says that they have actually read and agree with the document. This is important to ensure the quality and integrity of GGF deliverables. Thank you for your time. /Olle

1 0

Authority Recognition document now in public comment
by Olle Mulmo 31 Jan '05

31 Jan '05

Dear all, The outcome of the work accomplished in the Authority Recognition Research Group has entered a Public Comment period until February 24, 2005. Please visit http://www.ggf.org/Public_Comment_Docs/Public_Comment_Documents.htm and document your consent or disagreement with the document using the "Make Comments" form. You may be anonymous. Note that we also recommend that the authors and group members themselves to publicly provide a comment during this period that to an effect says that they have actually read and agree with the document. This is important to ensure the quality and integrity of GGF deliverables. Thank you for your time. /Olle

1 0

Semi-final FIG WG charter proposal
by Leon Gommans 13 Jan '05

13 Jan '05

Please below the semi-final charter proposal for a possible Firewall Issues Group that is intended to be formed within the security area. This charter has collected comments from this list. In particular the presence of host/application based firewalls functions are now mentioned. The charter also recognizes the fact that firewall policies may be generated automatically. Any further comments must be made soon as we want to go ahead and forward this proposal to our AD's within a few days. Kind regards - Leon Gommans, Inder Monga. ------- Firewall Issues Group (FIG). Chairs: Leon Gommans, Inder Monga Area Directors: Olle Mulmo, Dane Skow Mailing list: <tba> Description of Work: Grids increasingly require application driven transport privileges from the network. As such, the network is asked to make policy decisions on behalf of the various entities participating in an application's operation. A need has developed for Grid applications to communicate its requirements to the devices in the network that provide transport policy enforcement. Examples of such devices include firewalls, network address translators, and other gateway style devices. This working group will focus its attention to issues that Grid applications experience when the need arises to control firewall functions. Some examples are highlighted in GFD.37. The work will not preclude extensibility to other categories of what the IETF refers to as "middle-boxes". This working group will concern itself with an environment that consists of: - one or more firewalls in the data path. Firewalls may be external network devices or they may be integral to a host. There may also be application/xml-soap level firewalls involved. - a requesting Grid application - an optional policy decision point in which a firewall acts as enforcement point deploying models such as described in GFD.38. A requesting entity may be trusted or untrusted. In the case where it is trusted, the "middle box" will treat the request from the entity as authoritative. In the case where it is not trusted, the intermediate device will have to verify that it is authorized to complete the request. Authorization could originate from a separate, or a built in policy server. Policies can be created manually or automatically. The working group will evaluate existing IETF protocols for their applicability to the set of issues identified in the Grid and will deliver a document(s) that will recommend possible solutions and modifications to current protocols, if any, to the attention of the IETF. The output will be actively promoted within the firewall vendor community. The IETF work that will at least be considered is the output of the following groups: - midcom - "middlebox" communication: http://www.ietf.org/html.charters/midcom-charter.html - aft - Authenticated Firewall Traversal: http://www.ietf.org/html.charters/aft-charter.html - nsis - Next Steps in Signaling: http://www.ietf.org/html.charters/nsis-charter.html Input and participation from the vendor community is explicitly encouraged. Existing documents from the grid community will be used as starting point. Goals and Milestones: Submit after GGF15 informational document(s) that will focus on 1) An inventory of the issues with use-cases when Grid jobs must deal with firewall functions. 2) Subsequently technically describe and classify the issues in document #1 3) Evaluating existing IETF protocols and firewall functions for their suitability. 4) Recognize possible limitations of an identified firewall function and/or protocol and produce a list of requirements towards the IETF and interested firewall vendors. 5) Discuss and capture recommended approaches and solutions addressing the grid-specific issues and distribute towards the IETF and interested firewall vendors and capture results of 3-5 in document #2 GGF13: Charter discussion and group volunteers GGF14: First draft and Group discussions GGF15: Second draft and Group discussions. First draft of recommended approaches and solutions December 2005: WG last-call and final submission of document #1. GGF 16: Second draft and group discussions May 2006: WG last-call and final submission of document #2.

1 0

FW: **ACE-grid** GFD.43, "Security Requirements of Advanced Collaborative Environments (ACEs)" Published
by Markus Lorch 03 Jan '05

03 Jan '05

This document may be of interest to the security folks working with collaborative environments and to security architecture designers for middleware that aims to support such application software Markus -----Original Message----- From: Michael E. Papka Sent: Sonntag, 2. Januar 2005 06:40 Happy New Year, Just a short note, ACE has published its first GGF document "Security Requirements of Advanced Collaborative Environments (ACEs)" an informational document, you can find the final version at http://www.ggf.org/documents/final.htm Mike

1 0

Authorization Glossary Published, AuthZ WG closes down
by Markus Lorch 03 Jan '05

03 Jan '05

Hi all, Hope y'all had a couple of relaxing holidays and a good start into the New Year. I am happy to announce that the Authorization Frameworks and Mechanisms Working Group of the GGF has published its "Authorization Glossary" document as GFD-I.42. You can find the final version at http://www.ggf.org/documents/final.htm With the finalization of this document the AuthZ WG has accomplished the tasks outlined in its charter and is closing down. Markus ---------------------------------------------------------------- Markus Lorch Department of Computer Science Phone: +1 540 231 5914 Virginia Tech, m/c 106 Fax: +1 540 231 6075 Blacksburg, VA 24061, U.S.A. http://people.cs.vt.edu/~mlorch

1 0

RE: [security-area] FIG WG charter proposal
by Inder Monga 21 Dec '04

21 Dec '04

Matt, You bring up a good point. >From my perspective, I was looking at the firewall as a function in a more abstract way. This function could be deployed as part of the stack/middleware (on the same host) or as an independent entity (as a mid-box), and multiple such functions might need to be traversed. So even though issues/solutions might be similar , I agree that we still need to explicitly discuss these issues as related to different deployment use-cases. Creating a generic reference diagram capturing the various use-cases will be useful as part of the first document within the WG. Inder -----Original Message----- From: owner-security-area(a)ggf.org [mailto:owner-security-area@ggf.org] Sent: Monday, December 20, 2004 12:08 PM To: security-area(a)ggf.org Subject: Re: [security-area] FIG WG charter proposal Some grid resources operate at speeds beyond the range of current choke-point firewalls. I would like to see explicit mention in the charter of attention to the case where the firewall function is integral to the host. There may still be interaction with an external policy-control service for approval of rule changes. Matt Crawford <crawdad(a)fnal.gov> Fermilab Computer Security Coordinator

2 1

FIG WG charter proposal
by Leon Gommans 20 Dec '04

20 Dec '04

Please find below a proposed charter for a possible Firewall Issues Group that is intended to be formed within the security area. Any comments are welcome. Kind regards - Leon Gommans, Inder Monga. ------- Firewall Issues Group (FIG). Chairs: Leon Gommans, Inder Monga Area Directors: Olle Mulmo, Dane Skow Mailing list: <tba> Description of Work: Grids increasingly require application driven transport privileges from the network. As such, the network is asked to make policy decisions on behalf of the various entities participating in an application's operation. A need has developed for Grid applications to communicate its requirements to the devices in the network that provide transport policy enforcement. Examples of such devices include firewalls, network address translators, and other gateway style devices. This working group will focus its attention to issues that Grid applications experience when the need arises to control firewall functions. Some examples are highlighted in GFD.37. The work will not preclude extensibility to other categories of what the IETF refers to as "middle-boxes". This working group will concern itself with an environment that consists of: - one or more firewalls in the data path - a requesting Grid application - an optional policy decision point in which a firewall acts as enforcement point deploying models such as described in GFD.38. A requesting entity may be trusted or untrusted. In the case where it is trusted, the "middle box" will treat the request from the entity as authoritative. In the case where it is not trusted, the intermediate device will have to verify that it is authorized to complete the request. Authorization could originate from a separate, or a built in policy server. The working group will evaluate existing IETF protocols for their applicability to the set of issues identified in the Grid and will deliver a document(s) that will recommend possible solutions and modifications to current protocols, if any, to the attention of the IETF. The output will be actively promoted within the firewall vendor community. The IETF work that will at least be considered is the output of the following groups: - midcom - "middlebox" communication: http://www.ietf.org/html.charters/midcom-charter.html - aft - Authenticated Firewall Traversal: http://www.ietf.org/html.charters/aft-charter.html - nsis - Next Steps in Signaling: http://www.ietf.org/html.charters/nsis-charter.html Input and participation from the vendor community is explicitly encouraged. Existing documents from the grid community will be used as starting point. Goals and Milestones: Submit after GGF15 informational document(s) that will focus on 1) An inventory of the issues with use-cases when Grid jobs must deal with firewall functions. 2) Subsequently technically describe and classify the issues in document #1 3) Evaluating existing IETF protocols and firewall functions for their suitability. 4) Recognize possible limitations of an identified firewall function and/or protocol and produce a list of requirements towards the IETF and interested firewall vendors. 5) Discuss and capture recommended approaches and solutions addressing the grid-specific issues and distribute towards the IETF and interested firewall vendors and capture results of 3-5 in document #2 GGF13: Charter discussion and group volunteers GGF14: First draft and Group discussions GGF15: Second draft and Group discussions. First draft of recommended approaches and solutions December 2005: WG last-call and final submission of document #1. GGF 16: Second draft and group discussions May 2006: WG last-call and final submission of document #2.

3 2

Are we all lawless?
by Olle Mulmo 09 Dec '04

09 Dec '04

In recent meetings that I have attended, the issue that "VOs might not be legal" has surfaced a couple of times. Of course, the illegitimacy of a VO depends on you define and operate a VO for a certain community. But the basic argument goes like this: in a loosely coupled, non-centralized community, there is no point of control that can be held responsible for the sharing of information considered "sensitive" from a legal standpoint: Health and business regulations (not to mention data privacy laws) often require such a single entity. Other examples that fit this description is world-wide file-sharing of copyrighted material and cryptographic software. Does anyone have more insights on this matter? Regards, /Olle

4 3

FW: [AuthZ] Framework Document Published
by Olle Mulmo 25 Nov '04

25 Nov '04

-----Original Message----- From: owner-authz-wg(a)ggf.org [mailto:owner-authz-wg@ggf.org] On Behalf Of Markus Lorch Sent: Thursday, November 25, 2004 00:01 To: authz-wg(a)gridforum.org Subject: [AuthZ] Framework Document Published Hi AuthZ-WG, I am happy to announce that our framework document has been published as GFD.38 and is available from the GGF documents website at http://www.ggf.org/documents/final.htm (I noted that the GGF announcement and website does currently not list all the authors and have asked the GGF office to correct this) I'd like to thank all who contributed. Special thanks go to Bob Cowles, Mary Thompson, Marty Humphrey, and Olle Mulmo for their final reviews and helpful comments. Markus

1 0