Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Keith Moore moore@cs.utk.edu wrote: I don't think it's a good analogy because modem pools are very special-purpose devices, whereas a host can potentially do anything that needs to communicate with something else. For that matter, RADIUS doesn't have the intent of preventing some kinds of modem pools from connecting to the network. No, but it has the explicit intent of preventing some kinds of hosts from connecting to the network. Current RADIUS deployments implement almost anything you can imagine to control network access for hosts and/or users, down to filtering the users network traffic. Current RADIUS deployments *already* do ad-hoc posture assessment, there are a number of startups implementing this today. I don't see how NEA is such a big philosophical change from existing RADIUS practices. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Mike Fratto [EMAIL PROTECTED] wrote: At a very high level, this isn't much different than RADIUS, which defines the data formats and protocols between a network access device such as modem pool and the RADIUS server. Vendor specific attributes are supported and the standards don't attempt to provide *meaning*--that is left upto the vendor defining the specific attributes. To put it another way, many network access protocols (DHCP, RADIUS, etc.) have been doing posture assessment and network access control for a very long time. The concepts behind NEA are not new. The new part in NEA is the desire to do *more* than what the current access protocols have to offer. Even if NEA was to leverage existing protocols to their fullest extent, we would *still* need a standardized way to exchange the data needed to implement the more part of NEA. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Keith Moore moore@cs.utk.edu wrote: do you have actual statistics to back that up? It's not meant to be an exact number, but it's pretty close to being correct, in my experience. there are better (more reliable, more secure, more effective, cheaper) ways of providing a set of functions at a user terminal than to give everyone user-programmable machines and then have the network insist that they all have a rigidly controlled configuration... Yes. And there are mistakes in IETF protocols that have been deployed for decades, too. What are we supposed to tell the people who have billions of dollars invested in their current systems? You got it wrong, we're not going to come up with a solution to your problems. ? to me it seems to presuppose much more than that, by naming the kinds of actors and their roles. The actors and roles are nothing new. End-hosts, authentication servers, administrators, etc. have all been around for years. The NEA names are new, because people are starting to realize that there are classes of behavior that cannot be adequately described using the existing names. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Keith Moore moore@cs.utk.edu wrote: That seems overbroad, in particular because a laptop that connects to multiple networks cannot in general be expected to adhere to conflicting policies of the networks to which it connects. Exactly. That's why there are provisions for non-conforming systems. Network access can be denied entirely, or limited to the public (and unprotected) network. However, 99% of systems don't move networks, so those systems don't have a problem conforming to the local requirements. As far as I can tell, this is the crux of the problem with NEA - that in general it's simply unreasonable for a network to demand that every host that connect to it conform to arbitrary policies for configuration of those hosts. I'm not sure how to take this. It's unreasonable... OK, why? Is it unreasonable for me to require that I know which machines are on my network, or to deny access to machines I don't own? Given the remediation options outlined above, what part of controlling network access for unknown machines is unreasonable? The other problem I have with this charter is one that I have with many charters these days - it presupposes a particular design or architecture before the working group has actually met, when this should be an engineering decision taken by the consensus of the working group AFTER analysis of the problem space. I think it presupposes a particular problem, not an architecture. The problem is: a) knowing who is on my network b) controlling who is on my network c) controlling the behavior of the hosts on my network. If any of those problems are unreasonable to solve, then I would be *very* confused. The proposed NEA architecture derives directly from that problem statement. The *only* assumptions I see are: a) It's a good idea to know who's on my network b) It's a good idea for me to control who is on my network c) It's a good idea for me to control the behavior of hosts on my network d) all of the above is possible to implement e) Step (d) should be standardized Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
All, This charter is definitely clearer on some of the points that were discussed based on the last version, but a couple of things still remain to be clarified. Based on several discussions that we've had lately, I have two suggestions for further clarity: 1. Let's add the text suggested by Harald and Lakshminath (there seemed to be agreement on this text on the list). Quoting the change proposed: Replace: NEA can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties. with NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. 2. On the mandatory-to-implement PT protocol, I would like to see the clarification that the protocol must allow the NEA process to run either at the time of network access or while connected. This clarification seems mainly needed because there is text elsewhere in the charter about allowing NEA runs at network access or while connected - if that text is removed, this clarification won't be required. Thanks, Vidya -Original Message- From: IESG Secretary [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 12:50 PM To: ietf-announce@ietf.org Cc: [EMAIL PROTECTED] Subject: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following UPDATED draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 23rd. +++ Network Endpoint Assessment (nea) === Current Status: Proposed Working Group Chair(s): TBD Security Area Director(s): Russ Housley [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] Security Area Advisor: Russ Housley [EMAIL PROTECTED] Mailing List: [EMAIL PROTECTED] Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the posture of endpoint devices for the purposes of monitoring compliance to an organization's posture policy and optionally restricting access until the endpoint has been updated to satisfy the posture requirements. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. Note that an endpoint that is deemed compliant may still be vulnerable to unknown threats that may exist on the network. The network may thus continue to be exposed to such threats as well as the range of other threats not addressed by maintaining endpoint compliance. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge that software installed to protect the machine (e.g. patch management software, anti-virus software, host firewall software, host intrusion protection software or any custom software) is enabled and up-to-date. On network access and while connected, an endpoint supporting NEA protocols can be queried for such posture information. An organization may make a range of policy decisions based on the posture of an endpoint. NEA is not intended to be prescriptive in this regard. Supported deployment scenarios will include, but are not limited to, providing normal access regardless of compliance result along with any recommendations for remediation (advisory mode), as well as providing restricted access sufficient for remediation purposes and any essential services until an endpoint is in compliance (mandatory mode). Since NEA involves many different components from different vendors, interoperability is important. The priority of the NEA working group is to develop standard protocols at the higher layers in the architecture: the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). PA and PB will be designed to support a variety of lower layer protocols. When used with standards for lower layers, the PA and PB protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several non-standard protocols at these higher layers, the NEA working group will consider these existing protocols as candidates for the standard protocols. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Original Message All, This charter is definitely clearer on some of the points that were discussed based on the last version, but a couple of things still remain to be clarified. Based on several discussions that we've had lately, I have two suggestions for further clarity: 1. Let's add the text suggested by Harald and Lakshminath (there seemed to be agreement on this text on the list). Quoting the change proposed: Replace: NEA can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties. with NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. That seems overbroad, in particular because a laptop that connects to multiple networks cannot in general be expected to adhere to conflicting policies of the networks to which it connects. As far as I can tell, this is the crux of the problem with NEA - that in general it's simply unreasonable for a network to demand that every host that connect to it conform to arbitrary policies for configuration of those hosts. IETF should not be standardizing unreasonable expectations. And even if the behavior is in some limited set of circumstances reasonable (which is debatable), IMHO IETF should hesitate to define standards for corner cases. (I do sympathize with the notion that the biggest threats to an enterprise network are from the hosts that connect directly to it, and so it makes sense to concentrate efforts for protecting the network at the points where those hosts attach to the network) The other problem I have with this charter is one that I have with many charters these days - it presupposes a particular design or architecture before the working group has actually met, when this should be an engineering decision taken by the consensus of the working group AFTER analysis of the problem space. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
From: Keith Moore [mailto:[EMAIL PROTECTED] As far as I can tell, this is the crux of the problem with NEA - that in general it's simply unreasonable for a network to demand that every host that connect to it conform to arbitrary policies for configuration of those hosts. IETF should not be standardizing unreasonable expectations. And even if the behavior is in some limited set of circumstances reasonable (which is debatable), IMHO IETF should hesitate to define standards for corner cases. That is not my understanding of the problem statement. My understanding is that the specification will provide a description of the host configuration policy to the network, thus allowing the network to better decide whether to let the host connect. It is a network protocol, not an inter-network protocol. That is not new, DHCP is a network protocol and has no relevance to the inter-network. NEA is a security gloss on DHCP. (I do sympathize with the notion that the biggest threats to an enterprise network are from the hosts that connect directly to it, and so it makes sense to concentrate efforts for protecting the network at the points where those hosts attach to the network) The other problem I have with this charter is one that I have with many charters these days - it presupposes a particular design or architecture before the working group has actually met, when this should be an engineering decision taken by the consensus of the working group AFTER analysis of the problem space. That is the approach that the IETF has been configured for for 15 years. If you believe that a different architecture is appropriate you would have to convince people that that is the case. Working Groups that do no begin with a tightly defined architecture usually fail. There could be a role for the IAB to consider what the best overall Internet architecture is, but the IAB does not operate at that level. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
My network, my rules. If you don't like them go to the nearest Panera and use their free WiFi. If you want to connect to my network, my rules apply. That's not arbitrary, that's my right and my choice. perhaps. but I don't see why the IETF should provide tools to help you impose those rules - especially if to do so harms the flexibility of the Internet. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
As far as I can tell, this is the crux of the problem with NEA - that in general it's simply unreasonable for a network to demand that every host that connect to it conform to arbitrary policies for configuration of those hosts. IETF should not be standardizing unreasonable expectations. And even if the behavior is in some limited set of circumstances reasonable (which is debatable), IMHO IETF should hesitate to define standards for corner cases. That is not my understanding of the problem statement. My understanding is that the specification will provide a description of the host configuration policy to the network, thus allowing the network to better decide whether to let the host connect. that's my understanding also. but nothing you said here contradicts my statement. if connection of the host to the network is predicated on having the host conform to whatever arbitrary policy the network wishes to impose on how the host is configured, then it's unreasonable. the most that the network should be able to do is impose limitations on the kinds of traffic that host sends to or receives from the network. more broadly, the likely effect of standardizing a protocol that lets the network insist on a particular configuration for a host is to make the network less flexible over time, by reducing the number of kinds of hosts that can connect to a network. the unintended consequence of this proposal would thus be to reduce the flexibility of the Internet. It is a network protocol, not an inter-network protocol. true, but not relevant to this argument. The other problem I have with this charter is one that I have with many charters these days - it presupposes a particular design or architecture before the working group has actually met, when this should be an engineering decision taken by the consensus of the working group AFTER analysis of the problem space. That is the approach that the IETF has been configured for for 15 years. yes, and IMHO it's been wrong for 15 years. Working Groups that do no begin with a tightly defined architecture usually fail. that might say more about how WGs operate than anything else. we claim to do engineering around here, but the discipline of engineering requires that we understand a problem before we attempt to solve it. as long as we're not bothering to do that, we shouldn't be surprised when working groups produce solutions that don't solve problems. and there are plenty of these to be found in rfc-index.txt. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
From: Keith Moore [mailto:[EMAIL PROTECTED] that's my understanding also. but nothing you said here contradicts my statement. if connection of the host to the network is predicated on having the host conform to whatever arbitrary policy the network wishes to impose on how the host is configured, then it's unreasonable. So what if it is unreasonable. My network, my rules. If you don't like them go to the nearest Panera and use their free WiFi. If you want to connect to my network, my rules apply. That's not arbitrary, that's my right and my choice. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
From: Keith Moore [mailto:[EMAIL PROTECTED] My network, my rules. If you don't like them go to the nearest Panera and use their free WiFi. If you want to connect to my network, my rules apply. That's not arbitrary, that's my right and my choice. perhaps. but I don't see why the IETF should provide tools to help you impose those rules - especially if to do so harms the flexibility of the Internet. Because the architecture you propose is failed and unworkable. You are still stuck in the Internet of 1980, you are like the hippie who turns up at Aldermaston for the Ban the Bomb march with a sign saying 'ban the Gattlin Gun', possibly a relevant concern if the march was being held in 1910 but utterly irrelevant to the issue of the day. The Internet has a billion users and in the future it will be common for houses to have over a hundred network connected devices. Very few of those hundred network connected devices will or should be Internet connected. I do not care what you think I might need but I do not want to spend my time worrying whether Mr Coffee is hacking into the fridge or the microwave is hosting a kiddie porn site. The best way to stop such nonsense is to recognize what every mainstream security specialist working in the field recognized long ago - there is a difference between the network and the inter-network and connection to either is a privilege that should only be granted on the basis of need. Your political strategy is naïve and fragile. You mistake a tactic for a strategy. Insisting that every component that connects to any network be absolutely unrestricted in its capabilities is unworkable, unsustainable and violates the security principle of least privilege. It is a tactic that is doomed to failure. Your goal appears to be to ensure that individual Internet subscribers have unrestricted connectivity to the Internet. The appropriate strategy for that goal is a consumer reports type strategy, measure what is delivered, award seals of approval accordingly. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Hallam-Baker, Phillip wrote: The best way to stop such nonsense is to recognize what every mainstream security specialist working in the field recognized long ago - there is a difference between the network and the inter-network and connection to either is a privilege that should only be granted on the basis of need. Your political strategy is naïve and fragile. You mistake a tactic for a strategy. Insisting that every component that connects to any network be absolutely unrestricted in its capabilities is unworkable, unsustainable and violates the security principle of least privilege. It is a tactic that is doomed to failure. I think the problem that Keith is talking about is the problem of unreasonable policies, which will instantly create a criminal subculture in any networks that have such unreasonable policies. For example, if the only ISPs that are available to me insist that the machine I connect to their precious network run Windows XP SP foo, but I'm actually a Linux user, then techniques will emerge that allow me to fool the ISP into thinking that I'm a Windows XP SP foo machine. Trying to enforce that a Turing-complete machine have capabilities no greater than X might seem to an IT senior manager to be a really good idea, but in practical terms, it can't be done. And if you try to do this in any but the most tightly-purposed networks, rebellion will be the inevitable result. Some companies have an emerging draconian policy about users running only authorized software on their machines, with a cumbersome approvals process for any new software that someone might want to run on their machine. Which includes software written by the user themselves. That type of policy might be reasonable in a call-center, or some other tightly-purposed network, but it fails in the general case, and true enforcement is impossible. This emerging draconian policy is subtly re-defining that which constitutes useful work in many places such that the only authorized things you can do with your machine are to shuffle Word, PowerPoint, and Excel documents around, surf the Web, and e-mail your co-workers. If you want to do real work, you necessarily have to violate policy, or do your real work on a machine not subject to the policy. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
From: Marcus Leech [mailto:[EMAIL PROTECTED] I think the problem that Keith is talking about is the problem of unreasonable policies, which will instantly create a criminal subculture in any networks that have such unreasonable policies. The people talking about NEA are generally talking about securing corporate networks. For example, if the only ISPs that are available to me insist that the machine I connect to their precious network run Windows XP SP foo, but I'm actually a Linux user, then techniques will emerge that allow me to fool the ISP into thinking that I'm a Windows XP SP foo machine. And what if the cable company decides to only broadcast Fox News? This is a political issue and not a technical one. This is not the purpose for which the specification is being proposed. The fact that some people might use it for that purpose is irrelevant. Trying to enforce that a Turing-complete machine have capabilities no greater than X might seem to an IT senior manager to be a really good idea, but in practical terms, it can't be done. Of course it can. Simply put a trustworthy computing partition on the machine. Palladium is more than capable of providing a proof that would be prohibitively expensive to defeat. And if you try to do this in any but the most tightly-purposed networks, rebellion will be the inevitable result. So you accept that the abuse scenario is not credible. Some companies have an emerging draconian policy about users running only authorized software on their machines, with a cumbersome approvals process for any new software that someone might want to run on their machine. True, I expect this to become the default. Which includes software written by the user themselves. That type of policy might be reasonable in a call-center, or some other tightly-purposed network, but it fails in the general case, and true enforcement is impossible. This emerging draconian policy is subtly re-defining that which constitutes useful work in many places such that the only authorized things you can do with your machine are to shuffle Word, PowerPoint, and Excel documents around, surf the Web, and e-mail your co-workers. That is a matter for you to discuss with your employer. It is not something that a standards body should consider. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Hi Vidya Inline ... -Original Message- From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 2:15 AM To: iesg@ietf.org; ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) All, This charter is definitely clearer on some of the points that were discussed based on the last version, but a couple of things still remain to be clarified. Based on several discussions that we've had lately, I have two suggestions for further clarity: 1. Let's add the text suggested by Harald and Lakshminath (there seemed to be agreement on this text on the list). Quoting the change proposed: Replace: NEA can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties. with NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. I don't think there is consensus around this text, and I can think of existing deployment scenarios that might be ruled out by this text and also where it might be considered to be too broad. I would rather allow the WG the time to define terminology and discuss criteria that determine applicability, e.g. who owns the endpoint versus who manages the endpoint (these may be different), so that we can do a clearer job articulating this. I don't think we are going to complete this now, and given there is an explicit action in the charter to address applicability, I think this should be good enough. 2. On the mandatory-to-implement PT protocol, I would like to see the clarification that the protocol must allow the NEA process to run either at the time of network access or while connected. This clarification seems mainly needed because there is text elsewhere in the charter about allowing NEA runs at network access or while connected - if that text is removed, this clarification won't be required. I don't think this really matters, but in the interests of closing on this, will remove the text you refer to. Thanks Susan Thanks, Vidya -Original Message- From: IESG Secretary [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 12:50 PM To: ietf-announce@ietf.org Cc: [EMAIL PROTECTED] Subject: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following UPDATED draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 23rd. +++ Network Endpoint Assessment (nea) === Current Status: Proposed Working Group Chair(s): TBD Security Area Director(s): Russ Housley [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] Security Area Advisor: Russ Housley [EMAIL PROTECTED] Mailing List: [EMAIL PROTECTED] Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the posture of endpoint devices for the purposes of monitoring compliance to an organization's posture policy and optionally restricting access until the endpoint has been updated to satisfy the posture requirements. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. Note that an endpoint that is deemed compliant may still be vulnerable to unknown threats that may exist on the network. The network may thus continue to be exposed to such threats as well as the range of other threats not addressed by maintaining endpoint compliance. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge that software installed to protect the machine (e.g. patch management software, anti-virus software, host firewall software, host intrusion protection software or any custom software) is enabled and up-to-date. On network access and while connected, an endpoint supporting NEA protocols can be queried for such posture information. An organization may make a range of policy decisions based on the posture of an endpoint. NEA is not intended to be prescriptive in this regard. Supported deployment scenarios will include, but are not limited to, providing normal
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
My network, my rules. If you don't like them go to the nearest Panera and use their free WiFi. If you want to connect to my network, my rules apply. That's not arbitrary, that's my right and my choice. perhaps. but I don't see why the IETF should provide tools to help you impose those rules - especially if to do so harms the flexibility of the Internet. Because the architecture you propose is failed and unworkable. I didn't propose anything resembling an architecture. and the proposal at hand is an anti-architecture - it's something that destroys the possibility of a unifying theme. You are still stuck in the Internet of 1980, you are like the hippie who turns up at Aldermaston for the Ban the Bomb march with a sign saying 'ban the Gattlin Gun', possibly a relevant concern if the march was being held in 1910 but utterly irrelevant to the issue of the day. Phill, you are not in a very good position to be judging my character or trying to extrapolate what I've said into a model of how my mind works. You are too stuck in your own little world to understand mine. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Hallam-Baker, Phillip wrote: Trying to enforce that a Turing-complete machine have capabilities no greater than X might seem to an IT senior manager to be a really good idea, but in practical terms, it can't be done. Of course it can. Simply put a trustworthy computing partition on the machine. Palladium is more than capable of providing a proof that would be prohibitively expensive to defeat. I, and others, dispute that such proofs are proof of anything really meaningful, and that defeating them would be prohibitively expensive to defeat. But that is territory that is emphatically not part of the work of this group. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Whether a company manageing a network demands that all hosts meet a specific policy is a local policy issue and the charter specifically addresses this concern: An organization may make a range of policy decisions based on the posture of an endpoint. NEA is not intended to be prescriptive in this regard. what the WG charter says and how the WG output is used are different things. IMHO we need to consider the potential unintended consequences of our efforts in IETF, not just what we intend. network operators do not limit their use of technology to what we write in applicability statements. I think the intent of the working group is to standardize the data formats and protocols so that NEA components can talk together, not to say what to do with non-compliant hosts. That is a local policy decsion. But to get to that decision, the components first have to communicate. At a very high level, this isn't much different than RADIUS, which defines the data formats and protocols between a network access device such as modem pool and the RADIUS server. I don't think it's a good analogy because modem pools are very special-purpose devices, whereas a host can potentially do anything that needs to communicate with something else. For that matter, RADIUS doesn't have the intent of preventing some kinds of modem pools from connecting to the network. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
From: Keith Moore [mailto:[EMAIL PROTECTED] Because the architecture you propose is failed and unworkable. I didn't propose anything resembling an architecture. and the proposal at hand is an anti-architecture - it's something that destroys the possibility of a unifying theme. So you see your role as wrecking proposals rather than making constructive proposals of your own? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Hi Susan, Having the applicability text baselined in the charter is necessary in my view. The current charter text is vague (can be limited). If you want to propose a revision of the text that Harald, Vidya and I are ok with, please do so. Given that this is up for discussion and decision in 2 days, let's work quickly on it. thanks, Lakshminath At 09:39 AM 10/24/2006, Susan Thomson \(sethomso\) wrote: Hi Vidya Inline ... -Original Message- From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 2:15 AM To: iesg@ietf.org; ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) All, This charter is definitely clearer on some of the points that were discussed based on the last version, but a couple of things still remain to be clarified. Based on several discussions that we've had lately, I have two suggestions for further clarity: 1. Let's add the text suggested by Harald and Lakshminath (there seemed to be agreement on this text on the list). Quoting the change proposed: Replace: NEA can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties. with NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. I don't think there is consensus around this text, and I can think of existing deployment scenarios that might be ruled out by this text and also where it might be considered to be too broad. I would rather allow the WG the time to define terminology and discuss criteria that determine applicability, e.g. who owns the endpoint versus who manages the endpoint (these may be different), so that we can do a clearer job articulating this. I don't think we are going to complete this now, and given there is an explicit action in the charter to address applicability, I think this should be good enough. 2. On the mandatory-to-implement PT protocol, I would like to see the clarification that the protocol must allow the NEA process to run either at the time of network access or while connected. This clarification seems mainly needed because there is text elsewhere in the charter about allowing NEA runs at network access or while connected - if that text is removed, this clarification won't be required. I don't think this really matters, but in the interests of closing on this, will remove the text you refer to. Thanks Susan Thanks, Vidya -Original Message- From: IESG Secretary [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 17, 2006 12:50 PM To: ietf-announce@ietf.org Cc: [EMAIL PROTECTED] Subject: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following UPDATED draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 23rd. +++ Network Endpoint Assessment (nea) === Current Status: Proposed Working Group Chair(s): TBD Security Area Director(s): Russ Housley [EMAIL PROTECTED] Sam Hartman [EMAIL PROTECTED] Security Area Advisor: Russ Housley [EMAIL PROTECTED] Mailing List: [EMAIL PROTECTED] Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the posture of endpoint devices for the purposes of monitoring compliance to an organization's posture policy and optionally restricting access until the endpoint has been updated to satisfy the posture requirements. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. Note that an endpoint that is deemed compliant may still be vulnerable to unknown threats that may exist on the network. The network may thus continue to be exposed to such threats as well as the range of other threats not addressed by maintaining endpoint compliance. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge that software installed to protect the machine (e.g. patch management software, anti-virus software, host firewall software, host intrusion protection software or any custom software) is enabled and up-to-date. On network access
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Keith Moore writes... what the WG charter says and how the WG output is used are different things. IMHO we need to consider the potential unintended consequences of our efforts in IETF, not just what we intend. network operators do not limit their use of technology to what we write in applicability statements. Should I infer from this sentiment that you believe that the IETF ought to refrain from standardizing any technology that could be used by public or private network operators to discriminate against certain classes of clients, based on the posture of their hosts? I'll point out that only certain kinds of discrimination are undesirable, i.e. discrimination against protected classes. Other kinds of discrimination, e.g. helping to maintain a safe computing environment within a network, are highly desirable. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Keith Moore moore@cs.utk.edu wrote: That seems overbroad, in particular because a laptop that connects to multiple networks cannot in general be expected to adhere to conflicting policies of the networks to which it connects. Exactly. That's why there are provisions for non-conforming systems. Network access can be denied entirely, or limited to the public (and unprotected) network. However, 99% of systems don't move networks, so those systems don't have a problem conforming to the local requirements. do you have actual statistics to back that up? are 99% of hosts produced servers or desktops rather than laptops? and how are you defining a host, anyway? sorry, it just looks like a number picked out of thin air. even if the 99% figure is true today, will it be true in general in the future? personally I think that desktops as we know them are dinosaurs. they are too much of a security threat, too expensive to maintain, offer more flexibility than is needed, and are becoming a vector by which extortionist licensing fees can be extracted from owners. and the trend seems to be toward more and more mobile devices and special purpose devices. standards take a long time to produce and need to last a long time, so it make sense to define them in such a way as to be likely to continue to be useful for the foreseeable future. As far as I can tell, this is the crux of the problem with NEA - that in general it's simply unreasonable for a network to demand that every host that connect to it conform to arbitrary policies for configuration of those hosts. I'm not sure how to take this. It's unreasonable... OK, why? because the very nature of a personal computer is one in which every machine is customizable to suit the needs of the individual user. if the network takes away that flexibility, it also obviates the need for a user-programmable personal computer. there are better (more reliable, more secure, more effective, cheaper) ways of providing a set of functions at a user terminal than to give everyone user-programmable machines and then have the network insist that they all have a rigidly controlled configuration...and the only way to really get security out of PCs is to rigidly control their configurations. and furthermore if PCs continue to be user-programmable then it becomes possible to make NEA meaningless. (though the protocol could make it difficult for a host to forge assertions about itself by having the host sign the assertions with a key signed by the NEA software vendor, it would take some significant cleverness to prevent that key from being exposed to an attacker on that host, particularly one with physical access to the host). NEA isn't about knowing who is on your network in the sense of determining identity, it's about being able to delve into arbitrary details of host configuration. The other problem I have with this charter is one that I have with many charters these days - it presupposes a particular design or architecture before the working group has actually met, when this should be an engineering decision taken by the consensus of the working group AFTER analysis of the problem space. I think it presupposes a particular problem, not an architecture. The problem is: a) knowing who is on my network b) controlling who is on my network c) controlling the behavior of the hosts on my network. If any of those problems are unreasonable to solve, then I would be *very* confused. The proposed NEA architecture derives directly from that problem statement. to me it seems to presuppose much more than that, by naming the kinds of actors and their roles. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Hallam-Baker, Phillip wrote: From: Keith Moore [mailto:[EMAIL PROTECTED] that's my understanding also. but nothing you said here contradicts my statement. if connection of the host to the network is predicated on having the host conform to whatever arbitrary policy the network wishes to impose on how the host is configured, then it's unreasonable. So what if it is unreasonable. My network, my rules. If you don't like them go to the nearest Panera and use their free WiFi. If you want to connect to my network, my rules apply. That's not arbitrary, that's my right and my choice. I'm unclear on what host requirements NEA is proposing to add. The reality is that I have about 2 giant corporations to choose from for Internet connectivity where I live. I don't want either one of them installing mandatory software on my computers that denies access to the Internet if any unapproved applications are found. I would rather decide which applications I get to run, and if the ISP chooses to firewall certain protocols, then fine. Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
what the WG charter says and how the WG output is used are different things. IMHO we need to consider the potential unintended consequences of our efforts in IETF, not just what we intend. network operators do not limit their use of technology to what we write in applicability statements. Should I infer from this sentiment that you believe that the IETF ought to refrain from standardizing any technology that could be used by public or private network operators to discriminate against certain classes of clients, based on the posture of their hosts? I think it's dangerous territory, and IETF needs to be very careful about how the subject is approached. I don't think the current NEA charter reflects that kind of care, and I don't think that IETF processes for WG adoption really facilitate that kind of care. Within existing IETF structure defining the appropriate direction for a group like NEA probably calls for an IAB workshop - which unfortunately is a lot slower than you want if you're trying to ship product and have it blessed as a standard. Clearly there is some potential benefit at being able to identify hosts that present a risk to the network to which they are attached. But there's a very large and unpleasant camel attached to that nose. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Susan == Susan Thomson (sethomso) [EMAIL PROTECTED] writes: Susan Hi Vidya Inline ... -Original Message- From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 2:15 AM To: iesg@ietf.org; ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) All, This charter is definitely clearer on some of the points that were discussed based on the last version, but a couple of things still remain to be clarified. Based on several discussions that we've had lately, I have two suggestions for further clarity: 1. Let's add the text suggested by Harald and Lakshminath (there seemed to be agreement on this text on the list). Quoting the change proposed: Replace: NEA can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties. with NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. Susan I don't think there is consensus around this text, and I Susan can think of existing deployment scenarios that might be Susan ruled out by this text and also where it might be Susan considered to be too broad. Ah. Count me as one in favor of the text (although I do not object to the old text). I didn't speak up because I thought there was consensus. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
-Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 10:28 AM To: Susan Thomson (sethomso) Cc: Narayanan, Vidya; [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Susan == Susan Thomson (sethomso) [EMAIL PROTECTED] writes: Susan Hi Vidya Inline ... -Original Message- From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 2:15 AM To: iesg@ietf.org; ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) All, This charter is definitely clearer on some of the points that were discussed based on the last version, but a couple of things still remain to be clarified. Based on several discussions that we've had lately, I have two suggestions for further clarity: 1. Let's add the text suggested by Harald and Lakshminath (there seemed to be agreement on this text on the list). Quoting the change proposed: Replace: NEA can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties. with NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. Susan I don't think there is consensus around this text, and I Susan can think of existing deployment scenarios that might be Susan ruled out by this text and also where it might be Susan considered to be too broad. Ah. Count me as one in favor of the text (although I do not object to the old text). I didn't speak up because I thought there was consensus. I thought so as well. There were a few who explicitly agreed and I saw no disagreements on the list. Vidya ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
I don't see how NEA is such a big philosophical change from existing RADIUS practices. perhaps not, but I don't see how past mistakes are a justification for future ones. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
-Original Message- From: Alan DeKok [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 11:29 AM To: Keith Moore Cc: [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Keith Moore moore@cs.utk.edu wrote: I don't think it's a good analogy because modem pools are very special-purpose devices, whereas a host can potentially do anything that needs to communicate with something else. For that matter, RADIUS doesn't have the intent of preventing some kinds of modem pools from connecting to the network. No, but it has the explicit intent of preventing some kinds of hosts from connecting to the network. Current RADIUS deployments implement almost anything you can imagine to control network access for hosts and/or users, down to filtering the users network traffic. Current RADIUS deployments *already* do ad-hoc posture assessment, there are a number of startups implementing this today. I don't see how NEA is such a big philosophical change from existing RADIUS practices. I can sort of buy the analogy to RADIUS, although the AAA protocols are intended to do a lot more (the third A for instance). However, RADIUS doesn't inherently claim any security properties, while NEA seems to. RADIUS (or Diameter, for that matter) cannot really guarantee any level of security for network access control - that is dependent on what is carried in RADIUS (sometimes, a couple of levels down - e.g., EAP Method over EAP over RADIUS, where the strength is really dependent on the EAP method). Also, the strength of the second A in AAA depends on the kind of authorization policies in place. AAA is just a framework facilitating these - not a protocol that has some security claims to it. Vidya ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
Whether a company manageing a network demands that all hosts meet a specific policy is a local policy issue and the charter specifically addresses this concern: An organization may make a range of policy decisions based on the posture of an endpoint. NEA is not intended to be prescriptive in this regard. what the WG charter says and how the WG output is used are different things. IMHO we need to consider the potential unintended consequences of our efforts in IETF, not just what we intend. Keith, I have two big problems with this position. First of all, I have grave doubts our crystal ball is up to the task of forseeing all unintended consequences of the protocol we develope. So while I think some consideration of consequences is OK, we also need to keep in mind that we collectively pretty much suck at predicting the future. Second, consequences don't just attach to the roads we take, they also attach to the roads not taken. When we say no to something it often ends up being done in an ad hoc way that can potentially be far more damaging to the network than had we created a standard with the proper security mechanisms, applicability statements, and so on. I also think NEA is a good example of something that will cause a lot less problems if we do it right than if it is done in a bad and proprietary way. I started hearing talk about implementating NEA-like mechanisms at several large sites long before I ever heard of NEA. I therefroe believe that mechanisms to do this are going to be developed and deployed no matter what the IETF does. The only question is whether or not we're going to have a say in what gets done. I really don't want to see a situation arise where I can't use, say, my Linux laptop somwhere because the necessary secret handshake is some proprietary glop that only Windoze boxes can do. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
what the WG charter says and how the WG output is used are different things. IMHO we need to consider the potential unintended consequences of our efforts in IETF, not just what we intend. Keith, I have two big problems with this position. First of all, I have grave doubts our crystal ball is up to the task of forseeing all unintended consequences of the protocol we develope. So while I think some consideration of consequences is OK, we also need to keep in mind that we collectively pretty much suck at predicting the future. I agree. But we don't usually have to actually predict the future in order to make ourselves aware of the potential pitfalls associated with something that we're thinking about doing, and to take those pitfalls into account in a design. In the case of NEA those pitfalls aren't too hard to figure out, but nothing has been proposed to address those pitfalls other than inconsequential wording suggestions about the scope of the WG. The WG scope isn't the problem so much as the protocol itself. Figure out a way to keep the protocol from doing harm, and I'll be much more interested. Second, consequences don't just attach to the roads we take, they also attach to the roads not taken. When we say no to something it often ends up being done in an ad hoc way that can potentially be far more damaging to the network than had we created a standard with the proper security mechanisms, applicability statements, and so on. I agree also that this potential exists. One of the things that really bothers me about our WG creation process is that a lot of fundamental decisions about direction of a particular effort tend to be made with zero investigation of alternatives and little or no community input. Whatever gets written into the charter is essentially carved in stone, and sometimes the WGs don't even pay attention to whatever limitations are included in their charter - they just continue with whatever they started doing before the charter was approved. In the case of NEA (as in so many other cases) we (the wider community) are being presented with this as a done deal - either take this charter (modulo minor wording changes) or leave it. I sincerely believe that IETF can do something useful in this general space, but I also sincerely doubt that NEA is the right direction. And yet, we're already asking a yes or no question when it really should be a how can we address these problems? question. Is the wrong direction better than no contribution from IETF in this case? It's not entirely clear, but I suspect that in this case the answer is no. And yes, I'm also aware that historically when we charter a WG to study a problem and draft requirements, they tend to wallow around and not produce much of any use. I also think NEA is a good example of something that will cause a lot less problems if we do it right than if it is done in a bad and proprietary way. I started hearing talk about implementating NEA-like mechanisms at several large sites long before I ever heard of NEA. I therefroe believe that mechanisms to do this are going to be developed and deployed no matter what the IETF does. I agree. But is that really so bad? To me it isn't axiomatic that the Internet is better off if every application type that is widely deployed has a standard protocol. DRM is a good example - until DRM can, at a minimum, preserve a balance of interests between the public and rightsholders, the Internet is better off without standards for DRM. A similar argument can be made for NEA - there needs to be a way to preserve a balance between the rights of host owners and the rights of network owners. (one particularly chilling scenario is for a network to use NEA to force every host that connects to it to implement a form of DRM that compromises the interests of the public) The only question is whether or not we're going to have a say in what gets done. I really don't want to see a situation arise where I can't use, say, my Linux laptop somwhere because the necessary secret handshake is some proprietary glop that only Windoze boxes can do. IMHO, that is _more_ likely to happen if NEA is standardized than if there are some number of proprietary solutions. Ketih ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Douglas Otis [EMAIL PROTECTED] wrote: It seems impractical to specify system requirements or expect a suitable examination be done realtime prior to obtaining access. Maybe you're saying that a complete systems check would take too long. That is true, but that isn't how the NEA variants are being designed or deployed. Bad actors will always be able to falsify this information, so the NEA does not offer protection. This issue has already been discussed. The NEA should be viewed as a process that eliminates many of the security related support calls. That is not a priority for any customers I talked to. I've never head this as a justification for NEA from anyone. It seems impractical to expect NEA will prevent bad actors from producing the expected results. Which is why recent discussions on the NEA list made it clear that no one was expecting that from NEA. There are anti-virus and OS updating services that could produce a certificate that includes: ... Which is a good idea, and substantially similar to validation and remediation services currently offered. That information still has to be propogated to the device that controls network access. It seems unwise to expect an endpoint to open their robes to the access point. However, the access point could offer certification services they require prior to granting access. This service may be something as simple as agreeing to the AUP presented on a web-form, or agreeing to remedy the cause of abusive behavior. People are doing something similar to this today with quarantine networks, and remediation sites. But it's ad-hoc, and not automated. Rather than talking about the posture of the endpoint, consider the NEA to be little more than a repository for time- sensitive compliance certificates offering just the five points listed. Pretty much, yes. With the addition of a protocol to carry that information from the end point to elsewhere in the network. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Ted Hardie wrote: For the charter discussions, I want to know whether it will be an aim of the working group to standardize: * a way of carrying this information * the structure of this information (but not its content) * a standard representation of the content, so that access to the vendor database is no longer required I believe that we'll need to define all three of these. There may be times when access to an external database would be useful (if you want to know exactly which viruses are covered by which AV defs version, for example) but such access should not be required to use the standard attributes. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Lets not forget that when (not if) NEA/NAP/NAC is deployed the IDSen people have deployed today to solve the lying-client-problem by scanning for common/current vulnerabilities as part of the network admission process will have to interface with PDPs part of a NEA intfrastructure. Could you rephrase please? I am afraid I don't understand what you are saying. It has been pointed out on this list that the main deliverable from NEA might well turn out to be the way host postures are described - the schema if you will. I'm positive that if someone deployes NEA/NAP/NAC etc the admin will want to combine data from the on-client posture client with information from external IDS (etc) services to a common Policy Decision Point. That means that a reason to do NEA is to get this schema standardized even if some people who care about lying clients to never use and/or trust client posture clients. Oh, and lying endpoint problem cannot be solved by scanning for common vulnerabilities! In fact, the two have no relation whatsoever. They have the single relation of both expressing claims about the state of a host. Cheers Leif ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Noting the scenarios above, I claim that NEA-like functionality has proved useful already in protecting the computing environment of an enterprise. I have not seen compelling evidence that it has any use in the layer 3 infrastructure used to carry customer traffic at an ISP. But I think that's beside the point - the use cases for which we know that NEA may be useful are already compelling enough that we should stop debating whether or not to charter the group and get on with the work. My opinion. I concur. I will also add that my concerns about this work being used outside it's domain of applicability (which as a practical matter we have little control over) pale in comparison to concerns about there being mulitple proprietary schemes for this sort of thing. The last thing we need to be doing is encouraging monocultures through the work we do (or don't) do. I also think this discussion is well over the line of charter debate and into the realm of protocol design. Let's finalize the charter (I thought the latest proposed text regarding scope looked fine) and do the protocol work in the WG. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Sam Hartman wrote: One of the things coming out of the most recent BOF was a strong desire for PA-level interoperability. That can be accomplished through standardized attributes or vendor-specific attributes that are sufficiently well documented (and not subject to patents) that third parties can implement collectors or analysis tools that interoperate with the vendor tools for the vendor attributes. Will we be able to meet these interoperability goals? Why or why not? Yes, we can. If we define a small set of standardized attributes (OS and app version, AV status, etc.) and make them mandatory to implement, then we will have interoperability with respect to those attributes. We should allow the definition of attributes that go beyond this minimal standard mandatory to implement (MTI) set but the MTI set will provide a baseline of information available for all endpoints that implement NEA. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Narayanan, Vidya wrote: Harald, This seems to be missing the point. I think there is a general sense that NEA could be helpful for some level of protection to complying endpoints in an enterprise scenario, which is exactly what you have described below. The disagreement seems to be on the topics of what NEA does for the network and whether it makes any sense in the provider model where the network and end device owners are different. I'm not sure who is missing what point at this time note that the term network does NOT mean ISP network. People who use it as if it means that contribute to confusion. Also, the term network has been used both in the meaning of layer 3 network and in the meaning of the set of interconnected devices that make up the computing environment of an enterprise. On the network protection issue, I still have not seen anything that NEA provides that is not provided (in a better manner) by protection mechanisms that the network must use to protect itself against any unknown vulnerabilities and compromised endpoints. Everything that has been said still seems to be a subset of that larger threat which must be protected against anyway. Having said that, the use of NEA for the provider model doesn't make sense, since providers are interested in protecting their networks more than protecting the devices they don't own. Not to mention that they cannot really hope to get compliance from devices they don't own. Noting the scenarios above, I claim that NEA-like functionality has proved useful already in protecting the computing environment of an enterprise. I have not seen compelling evidence that it has any use in the layer 3 infrastructure used to carry customer traffic at an ISP. But I think that's beside the point - the use cases for which we know that NEA may be useful are already compelling enough that we should stop debating whether or not to charter the group and get on with the work. My opinion. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Vidya Narayanan wrote: I am very apprehensive of achieving any meaningful PA-level interoperability. I am not sure what minimum set of PA attributes will be standardized, but, whatever that set is, I doubt will be sufficient to provide any acceptable level of security, even for the endpoints. This is not surprising, since you have said that you don't see any security value to NEA. Even assuming ongoing standardization of vendor specific attributes, it is not totally realistic to assume that all applications will support the appropriate attributes. The rate of standardization is also very likely to be much slower than the rate of the growth in the number of attributes needed for any continued meaningful protection. NEA is not based on applications supporting attributes. Attributes are supported by Posture Collectors and Posture Validators, specialized NEA components. An AV Posture Collector will handle attributes pertaining to AV, perhaps by interfacing with an existing AV application. Still, I agree that a given endpoint will typically only support a small subset of the universe of possible attributes. Not a problem. As long as the endpoint supports enough attributes that the Posture Broker can evaluate its compliance with the posture policy, that's enough. Thanks, Steve -Original Message- From: Narayanan, Vidya [mailto:[EMAIL PROTECTED] Sent: Monday, October 16, 2006 5:06 PM To: Sam Hartman; Frank Yeh Jr Cc: Hardie, Ted; [EMAIL PROTECTED]; ietf@ietf.org Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Sam, -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 12:43 PM To: Frank Yeh Jr Cc: Hardie, Ted; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Frank == Frank Yeh [EMAIL PROTECTED] writes: Frank Standardized VS vendor-specific attributes is not something that needs to be Frank solved today. Solutions can start with vendor-specific and migrate toward a Frank standard, if one develops, without changing the protocol. The specification Frank should not preclude the addition of standardized attributes. IE the Frank specification is like an alphabet, attributes are like vocabulary. You can add Frank new words without changing the letters. One of the things coming out of the most recent BOF was a strong desire for PA-level interoperability. That can be accomplished through standardized attributes or vendor-specific attributes that are sufficiently well documented (and not subject to patents) that third parties can implement collectors or analysis tools that interoperate with the vendor tools for the vendor attributes. Will we be able to meet these interoperability goals? Why or why not? I am very apprehensive of achieving any meaningful PA-level interoperability. I am not sure what minimum set of PA attributes will be standardized, but, whatever that set is, I doubt will be sufficient to provide any acceptable level of security, even for the endpoints. Even assuming ongoing standardization of vendor specific attributes, it is not totally realistic to assume that all applications will support the appropriate attributes. The rate of standardization is also very likely to be much slower than the rate of the growth in the number of attributes needed for any continued meaningful protection. Regards, Vidya ___ Nea mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/nea ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
At 11:06 PM 10/16/2006, Harald Alvestrand wrote: Narayanan, Vidya wrote: Harald, snip Noting the scenarios above, I claim that NEA-like functionality has proved useful already in protecting the computing environment of an enterprise. I have not seen compelling evidence that it has any use in the layer 3 infrastructure used to carry customer traffic at an ISP. But I think that's beside the point - the use cases for which we know that NEA may be useful are already compelling enough that we should stop debating whether or not to charter the group and get on with the work. It seems that there are a number of people believing that NEA might be useful in Enterprise networks where the network and the endpoints attaching to the network are owned and controlled by the same entity. I know your words are proved useful; but perhaps we might agree that it's an arms race, so to speak. Note that the notion of proved useful is unlike the type of guarantees we are used to in the Security area. The charter currently says in part There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access. That is ambiguous. I suggested adding the following applicability statement before: NEA is applicable to networks where endpoints accessing the network are owned and tightly controlled by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. That also seems ambiguous as per the recent discussions, so I propose the following revision, based on your words Harald: NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. Let us make that change so it is clear to everyone as to what NEA might and might not do. Lakshminath My opinion. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
At 12:00 AM 10/17/2006, Khosravi, Hormuzd M wrote: Sam, I believe if we move 'quickly' in this WG we will be able to meet interoperability goals to certain extent atleast. The bottom-line is this technology is already being deployed by different vendors in academia and enterprises. The question is should IETF get involved in standardizing this or leave it to the individual vendors. I believe the IETF should and that standardization will certainly help the community, if we can move fast enough. Whereas interoperability is a noble goal, the IETF also has the good habit of clearly specifying what our protocols do and don't do. Our bar is thankfully higher than marketing literature for example. The recent email by Jari Arkko to standardize some of the EAP methods which are being used and deployed today but no RFCs exist for them, is certainly a step in the right direction. Good example actually: 3748 contains brutal truths about some of the legacy EAP methods, for instance on MD5-Challenge -- which no one should really be using for access control -- it says: Auth. mechanism: Password or pre-shared key. Ciphersuite negotiation: No Mutual authentication: No Integrity protection: No Replay protection: No Confidentiality: No Key derivation:No Key strength: N/A Dictionary attack prot.: No Fast reconnect:No Crypt. binding:N/A Session independence: N/A Fragmentation: No Channel binding: No In other words, someone who uses that protocol gets zilch! Now of course, in the real world, a variant of this protocol was used and soon after publicly demonstrated to be useless. best regards, Lakshminath My 2 cents, Hormuzd ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Lakshminath Dondeti wrote: At 11:06 PM 10/16/2006, Harald Alvestrand wrote: Narayanan, Vidya wrote: Harald, snip Noting the scenarios above, I claim that NEA-like functionality has proved useful already in protecting the computing environment of an enterprise. I have not seen compelling evidence that it has any use in the layer 3 infrastructure used to carry customer traffic at an ISP. But I think that's beside the point - the use cases for which we know that NEA may be useful are already compelling enough that we should stop debating whether or not to charter the group and get on with the work. It seems that there are a number of people believing that NEA might be useful in Enterprise networks where the network and the endpoints attaching to the network are owned and controlled by the same entity. I know your words are proved useful; but perhaps we might agree that it's an arms race, so to speak. Note that the notion of proved useful is unlike the type of guarantees we are used to in the Security area. The charter currently says in part There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access. That is ambiguous. I suggested adding the following applicability statement before: NEA is applicable to networks where endpoints accessing the network are owned and tightly controlled by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. That also seems ambiguous as per the recent discussions, so I propose the following revision, based on your words Harald: NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. Let us make that change so it is clear to everyone as to what NEA might and might not do. I don't think we have any proof that this statement is true. I can think of scenarios where NEA would be useful, but they depend on various circumstances that either would be very specialized or require a great deal of faith in order to believe they would happen. I suggest: All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
At 12:29 AM 10/17/2006, Harald Alvestrand wrote: Lakshminath Dondeti wrote: At 11:06 PM 10/16/2006, Harald Alvestrand wrote: Narayanan, Vidya wrote: Harald, snip snip NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective. Let us make that change so it is clear to everyone as to what NEA might and might not do. I don't think we have any proof that this statement is true. I can think of scenarios where NEA would be useful, but they depend on various circumstances that either would be very specialized or require a great deal of faith in order to believe they would happen. I suggest: All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. Ok. For the benefit of the editor: Let us replace: There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access. with NEA is applicable to computing environments of enterprises where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases. Lakshminath ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Network Endpoint Assessment (nea)
Ted, As I understand your concerns expressed below, you are concerned that standardizing attributes for NEA would be redundant and pointless: redundant because vendor-specific attributes will cover the same information in more detail and pointless because remediation will not be possible given the limited information available through the standardized attributes. Is that right? If so, maybe it would help to explain why we want to have standardized attributes. The goal is to ensure that any NEA endpoint and server can interoperate in a meaningful manner without making the assumption that endpoint and server have the same vendor plug-ins installed. For this to be true, we must ensure that every NEA endpoint provides a basic set of information to the NEA server. That basic set of information will be the standardized attributes. If the endpoint and server both understand vendor-specific attributes that provide more information, that's great. But we want to ensure a base level of interoperability. Yes, remediation may be difficult using only the information in the standardized attributes. But a captive portal technique can be used to provide information to the endpoint user about how to remediate. Thanks, Steve Ted Hardie wrote: I have a very basic fear that this working group is getting chartered with a bunch of aims added by people who will not take on the task of doing the work. After private discussion with folks involved, my sense is that the very core of this work is a perceived need to be able to pass opaque strings between a host and the network prior to the host attaching. Those opaque strings are, essentially, the vendor-specific strings currently associated with posture assessment. The standard protocol carrying these strings would connect on the network side to a system that has plug-ins which understand the vendor-specific strings. With a charter that clarified that this was intended to assist the end systems with vulnerabilities prior to attachment because the network they are attaching to might be filled with danger, I think this work would get done reasonably quickly. (As a control mechanism to protect the network, I agree with the point made clearly by others that this is not appropriate). I am less sure of the task of standardizing attributes. I am not sure that the number of attributes which can be standardized will ever be high enough to be truly useful, and I am pretty sure that all of these will be already covered by vendor-specific attributes. Since there must be an assessor in place on the client for those few standardized attributes to be assessed and that assessor will likely already have these covered by vendor-specific attributes, in other words, we seem to be standardizing redundancy. On the network attachment side, it is possible, of course, that an offer of remediation could be made based on just the standard attributes, but it seems far more likely that it would be a two step process (assess standard attributes, then pass vendor-specific attributes to vendor plug-in). Again, if the vendor's attributes cover the standard attributes, then this is largely redundant and may add measurable latency; it seems far more likely that step one would simply be skipped if there were a vendor-specific string and an available plug-in. Since there has to be an assessor, the first seems very likely to me. If you don't have a vendor's plug-in, then I suppose there is some chance that you will trust and act based on the standard attributes, but the chance of getting the right remediation seems pretty slight in those circumstances. Especially when many vulnerabilities are a combination of conditions, (Browser version Foo on OS patch level Bar) that you could remediate by upgrading either one, checking for and acting on the attributes which could be standardized seems of very, very limited utility. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
At 2:04 AM -0400 10/17/06, Stephen Hanna wrote: Will we be able to meet these interoperability goals? Why or why not? Yes, we can. If we define a small set of standardized attributes (OS and app version, AV status, etc.) and make them mandatory to implement, Sorry, but doesn't AV status above refer to the existing, proprietary anti-virus systems? How does standardizing an attribute for carrying that help create a standardized understanding of what it means?Don't I still have to treat that as, essentially, a vendor attribute, since I have to know which vendor statuses cover which vulnerabilities? Or do you mean there is some anti-virus software here? Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Ted, Sorry, but doesn't AV status above refer to the existing, proprietary anti-virus systems? How does standardizing an attribute for carrying that help create a standardized understanding of what it means?Don't I still have to treat that as, essentially, a vendor attribute, since I have to know which vendor statuses cover which vulnerabilities? Or do you mean there is some anti-virus software here? I would think that five or six values are appropriate: 1. Vendor name (string) 2. Vendor engine version (integer) 3. Vendor virus definitions version (integer) 4. Enabled? (binary) 5. Buggered? (binary) 6. Other gobbledigook the vendor wants to include that might get standardized later. (blob) I could envision 3 being a bit of an issue if it is possible to update specific viruses but not others. I would expect the normal enterprise administrator to be able to act on the first 5. The 6th is there as a placeholder. I'm not sure I'd trust 5 if it's false. I'd also suggest we're well into solving the problem at this point. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
At 8:22 PM +0200 10/17/06, Eliot Lear wrote: would think that five or six values are appropriate: 1. Vendor name (string) 2. Vendor engine version (integer) 3. Vendor virus definitions version (integer) 4. Enabled? (binary) 5. Buggered? (binary) 6. Other gobbledigook the vendor wants to include that might get standardized later. (blob) I could envision 3 being a bit of an issue if it is possible to update specific viruses but not others. Thanks for this. I was assuming we were talking primarily about a 1 and 3 combined value. As it stands now, you need access to the vendor's database to know what viruses are covered by any specific version (your 3). For the charter discussions, I want to know whether it will be an aim of the working group to standardize: * a way of carrying this information * the structure of this information (but not its content) * a standard representation of the content, so that access to the vendor database is no longer required The tasks are substantially different in scope, and the level of interoperabilty the community can expect from them are similarly different. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
On Oct 17, 2006, at 11:22 AM, Eliot Lear wrote: I would think that five or six values are appropriate: 1. Vendor name (string) 2. Vendor engine version (integer) 3. Vendor virus definitions version (integer) 4. Enabled? (binary) 5. Buggered? (binary) 6. Other gobbledigook the vendor wants to include that might get standardized later. (blob) This still seems like too much. Information offered for access can be contained within one or more certificates. The information within these certificates should be limited to a minimal set of values: 1) creator 2) class 3) user-host 4) time-stamp 5) update resources The essential information would be the creator/class/user-host/time- stamp fields. When protection is not enabled or is buggered, then a newer certificate should not be offered. The virus definitions or patch updates can be deduced from the time-stamp or by extensions added to class, i.e. AVX-VISTA-37. If a vulnerability is reported subsequent to the time-stamp regarding the creator/class of service, then a new certificate could be required. This would simplify tracking at the access point. By keeping the information exchanged and decisions limited to this minimal information, NEA should provide a valuable services in many environments. Perhaps there should be some consideration given regarding which sets of certificates are offered in various environments. Allowing the certificates to be accessed beyond an authentication process seems to increase security exposures. As this information is not trustworthy, there would be also little gained sharing this information elsewhere. In fact, sharing this information may increase infection rates when this aids malware. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Andy Bierman wrote: I don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks. Well, first of all I don't see why this is any different than a radius server. In fact it could be that the access box forwards information in a very similar way. But let's say that it doesn't work that way just for yucks. Another approach is that the clients themselves must have a server on them and the queries go the other way. In this case the server need only check either a source address or a transaction ID. Furthermore, there is no reason for clients outside of that AS to have access to that server, so it's a good candidate for an ACL. Of course this creates a risk of attack on the clients themselves, which brings me to one of my greater concerns: In many of the mechanisms that communicate between client and network we are not finding good ways to prove the legitimacy of the service to the client. This is an area that perhaps it would be good to get the IRTF to work on. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Lakshminath Dondeti wrote: At 01:42 AM 10/7/2006, Harald Alvestrand wrote: snip Many universities require their students to buy their own laptops, but prohibit certain types of activity from those laptops (like spamming, DDOS-attacks and the like). They would love to have the ability to run some kind of NEA procedure to ensure that laptops are reasonably virus-free and free from known vulnerabilities, and are important enough in their students' lives that they can probably enforce it without a complaint about violation of privacy. Just pointing out that there's one use case with user-managed endpoints where NEA is not obviously a bad idea. My email ventures into a bit of non-IETF territory, but we are discussing use cases, and so I guess it's on topic. Universities should be the last places to try antics like NEA. Whereas an operational network would be a priority to them, it is also important that they allow students to experiment with new applications. If we are believing that general purpose computing will be taken away from college students, we are indeed talking about a different world. In any event, the bottomline is NEA as a solution to network protection is a leaky bucket at best. NEA at best *may* raise the bar in attacking a closed network where endpoints are owned and tightly controlled by the organization that owns the network. Lets not forget that when (not if) NEA/NAP/NAC is deployed the IDSen people have deployed today to solve the lying-client-problem by scanning for common/current vulnerabilities as part of the network admission process will have to interface with PDPs part of a NEA intfrastructure. Cheers Leif ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Extreme clipping below: v) IDS/IPS to detect and prevent intrusions NEA might help here by providing a common semantics for communicating the result of IDS scans of hosts to policy decision points. Cheers Leif ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
At 01:46 AM 10/16/2006, Leif Johansson wrote: Lakshminath Dondeti wrote: At 01:42 AM 10/7/2006, Harald Alvestrand wrote: snip Many universities require their students to buy their own laptops, but prohibit certain types of activity from those laptops (like spamming, DDOS-attacks and the like). They would love to have the ability to run some kind of NEA procedure to ensure that laptops are reasonably virus-free and free from known vulnerabilities, and are important enough in their students' lives that they can probably enforce it without a complaint about violation of privacy. Just pointing out that there's one use case with user-managed endpoints where NEA is not obviously a bad idea. My email ventures into a bit of non-IETF territory, but we are discussing use cases, and so I guess it's on topic. Universities should be the last places to try antics like NEA. Whereas an operational network would be a priority to them, it is also important that they allow students to experiment with new applications. If we are believing that general purpose computing will be taken away from college students, we are indeed talking about a different world. In any event, the bottomline is NEA as a solution to network protection is a leaky bucket at best. NEA at best *may* raise the bar in attacking a closed network where endpoints are owned and tightly controlled by the organization that owns the network. Lets not forget that when (not if) NEA/NAP/NAC is deployed the IDSen people have deployed today to solve the lying-client-problem by scanning for common/current vulnerabilities as part of the network admission process will have to interface with PDPs part of a NEA intfrastructure. Could you rephrase please? I am afraid I don't understand what you are saying. Oh, and lying endpoint problem cannot be solved by scanning for common vulnerabilities! In fact, the two have no relation whatsoever. Lakshminath Cheers Leif ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Eliot Lear wrote: Andy Bierman wrote: I don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks. Well, first of all I don't see why this is any different than a radius server. In fact it could be that the access box forwards information in a very similar way. But let's say that it doesn't work that way just for yucks. Another approach is that the clients themselves must have a server on them and the queries go the other way. In this case the server need only check either a source address or a transaction ID. Furthermore, there is no reason for clients outside of that AS to have access to that server, so it's a good candidate for an ACL. Of course this creates a risk of attack on the clients themselves, which brings me to one of my greater concerns: In many of the mechanisms that communicate between client and network we are not finding good ways to prove the legitimacy of the service to the client. This is an area that perhaps it would be good to get the IRTF to work on. My comment was on Harald's characterization of this work effort as 'low hanging fruit'. IMO, that term is reserved for huge gains for very little effort. I don't think that is the case here. Eliot Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Greetings, todd glassey [EMAIL PROTECTED] wrote on 10/13/2006 05:56:42 AM: So then this is an attempt by Cisco and IBM and several others to qualify a SOX reporting and compliance tool - get real. Todd Glassey I'm not sure I follow how you can infer that post-admission status checks are Cisco and IBM's attempt to qualify a SOX reporting and compliance tool. That's one of the wildest leaps of (il)logic I have seen. While my comments here do not represent IBM in any official capacity I can say that IMHO, a Sox compliance and reporting tool based solely on NEA (or Cisco NAC or TNC) would be woefully inadequate. Could the data collected for an NEA posture check be stored as part of an audit trail and would this data be useful? Absolutely! Does that make this a Sox compliance and reporting tool? No way! It would just become another trail of interesting information that would be aggregated in a REAL compliance and reporting tool. One might also consider that the original post concerned post-admission integrity checking as opposed to checking at admission only. The data collected during the admission process would be just as suitable for compliance and reporting as post-admission data. So why does the addition of post-admission checking suddenly make this a compliance and reporting tool? While logic can sometimes be dangerous (my logic is undeniable), I tend to rely on it in the absence of anything better. I don't understand the logic behind your statement. Regards, Frank Yeh - Original Message - From: Frank Yeh Jr To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] ; ietf@ietf.org Sent: Thursday, October 12, 2006 3:32 PM Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Greetings, Both of the existing flavors of NEA-type protocols (Cisco NAC and TNC) provide some mechanisms for integrity checking after the admission process has completed and removing an endpoint's privileged access if it falls out of compliance. So IMHO, support for post-admission integrity checking willbe expected in NEA. Collector/Verifier pairs can use NEA for pre-admission integrity checking and some other protocol for post-admission checking but if a post-admission violation is found, there should be a mechanism to terminate the user's current admission session and restart the admission process. Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software [image removed] Darryl \(Dassa\) Lynch [EMAIL PROTECTED] Darryl \(Dassa\) Lynch [EMAIL PROTECTED] 10/12/2006 02:27 PM Please respond to [EMAIL PROTECTED] [image removed] To [image removed] [EMAIL PROTECTED] [image removed] cc [image removed] ietf@ietf.org [image removed] Subject [image removed] RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) [image removed] [image removed] Douglas Otis wrote: If an application happens to be malware, it seems it would be unlikely stop these applications. How about: vi) Provide application level advisory information pertaining to available services. Points that seem to be missing are: vii) Notification of non-compliance. (Perhaps this could become a restatement of i.) viii) Time or sequence sensitive compliance certificates provided following a remediation process or service. Often bad behavior is detected, such as scanning or sending spam which may violate AUPs. These violations may trigger a requirement for the endpoint to use a service that offers remedies the endpoint might use. There could then be a time-sensitive certificate of compliance offered following completion of a check-list and an agreement to comply with the recommendations. Those that remain infected after remediation, or that ignore the AUPs and are again detected, may find this process a reason to correct the situation or their behavior, or the provider may wish to permanently disable the account. Am I mistaken or is NEA intended to be a compliance check before a node is allowed onto the network? As such, observed behaviour and application abuse would seem to be issues that would be dealt with by other tools. NEA may be used to ensure certain applications are installed and some other characteristics of the node but actual behaviour may not be evident until such time as the node has joined the network and would be beyond the scope of detection by NEA IMHO. NEA may be used to assist in limiting the risk of such behaviour but that is about the extent of it that I see. My reading of the charter gives me the impression NEA is only intended for a specific task and some of what we have been discussing seems to extend well beyond the limited scope proposed. Darryl (Dassa) Lynch ___ Nea mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/nea
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Sam, -Original Message- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 12:43 PM To: Frank Yeh Jr Cc: Hardie, Ted; [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Frank == Frank Yeh [EMAIL PROTECTED] writes: Frank Standardized VS vendor-specific attributes is not something that needs to be Frank solved today. Solutions can start with vendor-specific and migrate toward a Frank standard, if one develops, without changing the protocol. The specification Frank should not preclude the addition of standardized attributes. IE the Frank specification is like an alphabet, attributes are like vocabulary. You can add Frank new words without changing the letters. One of the things coming out of the most recent BOF was a strong desire for PA-level interoperability. That can be accomplished through standardized attributes or vendor-specific attributes that are sufficiently well documented (and not subject to patents) that third parties can implement collectors or analysis tools that interoperate with the vendor tools for the vendor attributes. Will we be able to meet these interoperability goals? Why or why not? I am very apprehensive of achieving any meaningful PA-level interoperability. I am not sure what minimum set of PA attributes will be standardized, but, whatever that set is, I doubt will be sufficient to provide any acceptable level of security, even for the endpoints. Even assuming ongoing standardization of vendor specific attributes, it is not totally realistic to assume that all applications will support the appropriate attributes. The rate of standardization is also very likely to be much slower than the rate of the growth in the number of attributes needed for any continued meaningful protection. Regards, Vidya ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Harald, This seems to be missing the point. I think there is a general sense that NEA could be helpful for some level of protection to complying endpoints in an enterprise scenario, which is exactly what you have described below. The disagreement seems to be on the topics of what NEA does for the network and whether it makes any sense in the provider model where the network and end device owners are different. On the network protection issue, I still have not seen anything that NEA provides that is not provided (in a better manner) by protection mechanisms that the network must use to protect itself against any unknown vulnerabilities and compromised endpoints. Everything that has been said still seems to be a subset of that larger threat which must be protected against anyway. Having said that, the use of NEA for the provider model doesn't make sense, since providers are interested in protecting their networks more than protecting the devices they don't own. Not to mention that they cannot really hope to get compliance from devices they don't own. Vidya -Original Message- From: Harald Alvestrand [mailto:[EMAIL PROTECTED] Sent: Friday, October 13, 2006 6:24 AM To: Alan DeKok Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) A typical NEA case (taken out of what Cisco's NAC is supposed to be good for): - Worker goes on holiday, takes laptop - New attack is discovered that exploits a newly discovered Windows vulnerability - Patch is created, distributed and installed - NEA posture requirement is increased to must have patch - Worker comes back, plugs in laptop Without NEA-like functionality: - Worker is admitted - Worker gets attacked compromised - IDS other alarms go off - Remediation efforts do what they usually do With NEA: - Worker gets sandboxed - Worker gets upgraded - Worker gets admitted - No compromise, so no remediation No ill intent on the part of any participant (except the attacker). Just a TCO issue. The fact that some fruit is low-hanging doesn't mean it's not worth picking. Harald Alan DeKok wrote: Brian E Carpenter [EMAIL PROTECTED] wrote: What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? Yes, that's a problem with NEA. No, it's not a problem for many (if not most) people using NEA. The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. No one can prevent a determined attacker from getting in. But by providing fewer hosts for him to attack, the attacks become less feasibly, and more visible. Alan DeKok. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
On Oct 12, 2006, at 2:27 PM, Darryl ((Dassa)) Lynch wrote: Am I mistaken or is NEA intended to be a compliance check before a node is allowed onto the network? It seems impractical to specify system requirements or expect a suitable examination be done realtime prior to obtaining access. NEA should be seen more as a notification process with the goal of avoiding self inflicted trouble tickets. Bad actors will always be able to falsify this information, so the NEA does not offer protection. As such, observed behaviour and application abuse would seem to be issues that would be dealt with by other tools. Agreed. When these other tools withdraw services after bad behavior is detected, NEA can notify the endpoint nothing is malfunctioning, but rather these services have been withheld. A selection of certificates may then be required before additional (or any) services are subsequently granted. The NEA should be viewed as a process that eliminates many of the security related support calls. NEA may be used to ensure certain applications are installed and some other characteristics of the node but actual behaviour may not be evident until such time as the node has joined the network and would be beyond the scope of detection by NEA IMHO. NEA may be used to assist in limiting the risk of such behaviour but that is about the extent of it that I see. It seems impractical to expect NEA will prevent bad actors from producing the expected results. There is little that prevents the NEA from providing falsified information. There are anti-virus and OS updating services that could produce a certificate that includes: 1) certificate creator for validation 2) a time-stamp 3) class 4) the user/host identifier 5) resources required for updating the certificate It seems unwise to expect an endpoint to open their robes to the access point. However, the access point could offer certification services they require prior to granting access. This service may be something as simple as agreeing to the AUP presented on a web-form, or agreeing to remedy the cause of abusive behavior. The NEA should also be helpful in deciding whether a range of services are acceptable, and how this can be changed. Perhaps different certificates are required before specific services are granted. Rather than talking about the posture of the endpoint, consider the NEA to be little more than a repository for time- sensitive compliance certificates offering just the five points listed. My reading of the charter gives me the impression NEA is only intended for a specific task and some of what we have been discussing seems to extend well beyond the limited scope proposed. It seems that the NEA charter delves into too many details. The NEA can act as a bidirectional notification of services. From the access standpoint, these are services granted and compliance services required to upgrade what is being granted. From the endpoint standpoint, their certificates indicate which compliance services have been previously obtained, and the resources needed to renew these certificates when they are considered out-of-date by the access point. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Harald Alvestrand wrote: A typical NEA case (taken out of what Cisco's NAC is supposed to be good for): - Worker goes on holiday, takes laptop - New attack is discovered that exploits a newly discovered Windows vulnerability - Patch is created, distributed and installed - NEA posture requirement is increased to must have patch - Worker comes back, plugs in laptop Without NEA-like functionality: - Worker is admitted - Worker gets attacked compromised - IDS other alarms go off - Remediation efforts do what they usually do With NEA: - Worker gets sandboxed - Worker gets upgraded - Worker gets admitted - No compromise, so no remediation No ill intent on the part of any participant (except the attacker). Just a TCO issue. The fact that some fruit is low-hanging doesn't mean it's not worth picking. I don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks. Harald Andy Alan DeKok wrote: Brian E Carpenter [EMAIL PROTECTED] wrote: What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? Yes, that's a problem with NEA. No, it's not a problem for many (if not most) people using NEA. The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. No one can prevent a determined attacker from getting in. But by providing fewer hosts for him to attack, the attacks become less feasibly, and more visible. Alan DeKok. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Brian E Carpenter [EMAIL PROTECTED] wrote: What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? Yes, that's a problem with NEA. No, it's not a problem for many (if not most) people using NEA. The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. No one can prevent a determined attacker from getting in. But by providing fewer hosts for him to attack, the attacks become less feasibly, and more visible. Alan DeKok. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Greetings, Both of the existing flavors of NEA-type protocols (Cisco NAC and TNC) provide some mechanisms for integrity checking after the admission process has completed and removing an endpoint's privileged access if it falls out of compliance. So IMHO, support for post-admission integrity checking willbe expected in NEA. Collector/Verifier pairs can use NEA for pre-admission integrity checking and some other protocol for post-admission checking but if a post-admission violation is found, there should be a mechanism to terminate the user's current admission session and restart the admission process. Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software Darryl \(Dassa\) Lynch [EMAIL PROTECTED] Darryl \(Dassa\) Lynch [EMAIL PROTECTED] 10/12/2006 02:27 PM Please respond to [EMAIL PROTECTED] To [EMAIL PROTECTED] cc ietf@ietf.org Subject RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Douglas Otis wrote: If an application happens to be malware, it seems it would be unlikely stop these applications. How about: vi) Provide application level advisory information pertaining to available services. Points that seem to be missing are: vii) Notification of non-compliance. (Perhaps this could become a restatement of i.) viii) Time or sequence sensitive compliance certificates provided following a remediation process or service. Often bad behavior is detected, such as scanning or sending spam which may violate AUPs. These violations may trigger a requirement for the endpoint to use a service that offers remedies the endpoint might use. There could then be a time-sensitive certificate of compliance offered following completion of a check-list and an agreement to comply with the recommendations. Those that remain infected after remediation, or that ignore the AUPs and are again detected, may find this process a reason to correct the situation or their behavior, or the provider may wish to permanently disable the account. Am I mistaken or is NEA intended to be a compliance check before a node is allowed onto the network? As such, observed behaviour and application abuse would seem to be issues that would be dealt with by other tools. NEA may be used to ensure certain applications are installed and some other characteristics of the node but actual behaviour may not be evident until such time as the node has joined the network and would be beyond the scope of detection by NEA IMHO. NEA may be used to assist in limiting the risk of such behaviour but that is about the extent of it that I see. My reading of the charter gives me the impression NEA is only intended for a specific task and some of what we have been discussing seems to extend well beyond the limited scope proposed. Darryl (Dassa) Lynch ___ Nea mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/nea ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re:[Nea] WG Review: Network Endpoint Assessment (nea)
I have a very basic fear that this working group is getting chartered with a bunch of aims added by people who will not take on the task of doing the work. After private discussion with folks involved, my sense is that the very core of this work is a perceived need to be able to pass opaque strings between a host and the network prior to the host attaching. Those opaque strings are, essentially, the vendor-specific strings currently associated with posture assessment.The standard protocol carrying these strings would connect on the network side to a system that has plug-ins which understand the vendor- specificstrings. With a charter that clarified that this was intended to assist the end systems with vulnerabilities prior to attachment because the network they are attaching to might be filled with danger, I think this work would get done reasonably quickly. (As a control mechanism to protect the network, I agree with the point made clearly by others that this is not appropriate). I am less sure of the task of standardizing attributes. I am not sure that the number of attributes which can be standardized will ever be high enough to be truly useful, and I am pretty sure that all of these will be already covered by vendor-specific attributes.Since there must be an assessor in place on the client for those few standardized attributes to be assessed and that assessor will likely already have these covered by vendor-specific attributes, in other words, we seem to be standardizing redundancy. On the network attachment side, it is possible, of course, that an offer of remediation could be made based on just the standard attributes, but it seems far more likely that it would be a two step process (assess standard attributes, then pass vendor-specific attributes to vendor plug-in). Again, if the vendor's attributes cover the standard attributes, then this is largely redundantand may add measurable latency; it seems far more likely that step one would simply be skipped if there were a vendor-specific stringand an available plug-in. Since there has to be an assessor, the first seems very likely to me. If you don't have a vendor's plug-in, then I suppose there is some chance that you will trust and act based on the standard attributes, but the chance of getting the right remediation seems pretty slight in those circumstances. Especially when many vulnerabilitiesare a combination of conditions, (Browser version Foo on OS patch level Bar) that you could remediate by upgrading either one, checking for and acting on the attributes which could be standardized seems of very, very limited utility. I think that most function should be completed through vendor-specific attributes and standard attributes are only basic information. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Ted Hardie [EMAIL PROTECTED] wrote on 10/08/2006 11:45:37 PM: [snip] my sense is that the very core of this work is a perceived need to be able to pass opaque strings between a host and the network prior to the host attaching. Yes, that is the essence of this work which is what we need to remember and focus on. It will probably be applied for various purposes. Those opaque strings are, essentially, the vendor-specific strings currently associated with posture assessment. The standard protocol carrying these strings would connect on the network side to a system that has plug-ins which understand the vendor-specific strings. With a charter that clarified that this was intended to assist the end systems with vulnerabilities prior to attachment because the network they are attaching to might be filled with danger, I think this work would get done reasonably quickly. (As a control mechanism to protect the network, I agree with the point made clearly by others that this is not appropriate). There seems to be confusion as two why people would want to do this. In one sense we can protect things by not giving compromised endpoints access to network-attached resources, including parts of the network itself. This application has caused significant discussion as to the security of the protocol and solutions using it, which promises to be a subject of debate for the near future. Another way of looking at this is that it allows customers to use the network to enforce endpoint compliance to policy and provide a convenient place to challenge endpoints, collect data from them, thus providing an audit trail. I am less sure of the task of standardizing attributes. I am not sure that the number of attributes which can be standardized will ever be high enough to be truly useful, and I am pretty sure that all of these will be already covered by vendor-specific attributes. Since there must be an assessor in place on the client for those few standardized attributes to be assessed and that assessor will likely already have these covered by vendor-specific attributes, in other words, we seem to be standardizing redundancy. On the network attachment side, it is possible, of course, that an offer of remediation could be made based on just the standard attributes, but it seems far more likely that it would be a two step process (assess standard attributes, then pass vendor-specific attributes to vendor plug-in). Again, if the vendor's attributes cover the standard attributes, then this is largely redundant and may add measurable latency; it seems far more likely that step one would simply be skipped if there were a vendor-specific string and an available plug-in. Since there has to be an assessor, the first seems very likely to me. If you don't have a vendor's plug-in, then I suppose there is some chance that you will trust and act based on the standard attributes, but the chance of getting the right remediation seems pretty slight in those circumstances. Especially when many vulnerabilities are a combination of conditions, (Browser version Foo on OS patch level Bar) that you could remediate by upgrading either one, checking for and acting on the attributes which could be standardized seems of very, very limited utility. Standardized VS vendor-specific attributes is not something that needs to be solved today. Solutions can start with vendor-specific and migrate toward a standard, if one develops, without changing the protocol. The specification should not preclude the addition of standardized attributes. IE the specification is like an alphabet, attributes are like vocabulary. You can add new words without changing the letters. Ted Hardie ___ Nea mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/nea Frank Yeh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Alan DeKok writes: The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. I think the requirements document and/or charter would do well to stress this. Perhaps even exclude the 1% case explicitly. Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Frank == Frank Yeh [EMAIL PROTECTED] writes: Frank Standardized VS vendor-specific attributes is not something that needs to be Frank solved today. Solutions can start with vendor-specific and migrate toward a Frank standard, if one develops, without changing the protocol. The specification Frank should not preclude the addition of standardized attributes. IE the Frank specification is like an alphabet, attributes are like vocabulary. You can add Frank new words without changing the letters. One of the things coming out of the most recent BOF was a strong desire for PA-level interoperability. That can be accomplished through standardized attributes or vendor-specific attributes that are sufficiently well documented (and not subject to patents) that third parties can implement collectors or analysis tools that interoperate with the vendor tools for the vendor attributes. Will we be able to meet these interoperability goals? Why or why not? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Due process [Re: [Nea] WG Review: Network Endpoint Assessment (nea)]
Noel Chiappa wrote: From: Steven M. Bellovin [EMAIL PROTECTED] it is better that we aren't copied because to do so would be unfair to the complainer(s). As much as I've sparred with Glassey in the past ... I think he's right in this case. In my opinion, any sort of disciplinary action needs to be *perceived* as fair. ... I think we do need to follow due process. I'm going to disagree with you on this. My reasoning is that the decision of whether or not to suspend should be based almost entirely on the target person's posts, so the identity (and, indeed, the number) of people complaining is basically irrelevant. I see no failure of due process in the Sergeants At Arms stating that they have received a number of complaints about messages which were sent to a couple of thousand people. It isn't as if the complainers were making an attack on the sender of the messages; they were complaining that the messages were disrupting normal discussion on the list. Such complaints don't need to be public in order to be valid. I don't want to substitute my judgement for that of the Sergeants; but I think they have done the right thing. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Due process [Re: [Nea] WG Review: Network Endpoint Assessment (nea)]
Brian - what constitutes 'disrupting the normal conversation of the list' - disagreeing with the management of the list?. The issue isn't that I wasn't contributing - it was that the IPR and IP teams and the IETF process teams WILL NOT LET ME PARTICIPATE because I bring in non-engineering concerns with their IETF Operation's designs which makes them look like what they are - engineers instead of what they should be Operations Research or HR trained people so that they can look at human dynamics better. Your problem is that the LIST STRUCTURE of these entities DO NOT WANT ANYONE ELSE IN THE IETF TO KNOW WHAT THEY ARE DOING... What do you think would happen if a Broadcast Message was sent to the MEMBERSHIP of the IETF saying that the IPR WG was changing the LEGAL CONSTRAINTS that controlled their participation and that when it was done they would need to have their Sponsor's attorney's look it over to make sure it was 'clean' and appropopriate for them to continue participating under the new rules. By the way - if this IETF was audited - every one of my complaints would have been substantiated. Todd Glassey - Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: ietf@ietf.org Sent: Thursday, October 12, 2006 2:55 AM Subject: Due process [Re: [Nea] WG Review: Network Endpoint Assessment (nea)] Noel Chiappa wrote: From: Steven M. Bellovin [EMAIL PROTECTED] it is better that we aren't copied because to do so would be unfair to the complainer(s). As much as I've sparred with Glassey in the past ... I think he's right in this case. In my opinion, any sort of disciplinary action needs to be *perceived* as fair. ... I think we do need to follow due process. I'm going to disagree with you on this. My reasoning is that the decision of whether or not to suspend should be based almost entirely on the target person's posts, so the identity (and, indeed, the number) of people complaining is basically irrelevant. I see no failure of due process in the Sergeants At Arms stating that they have received a number of complaints about messages which were sent to a couple of thousand people. It isn't as if the complainers were making an attack on the sender of the messages; they were complaining that the messages were disrupting normal discussion on the list. Such complaints don't need to be public in order to be valid. I don't want to substitute my judgement for that of the Sergeants; but I think they have done the right thing. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
On Tue, 2006-10-10 at 20:01 -0700, Narayanan, Vidya wrote: I am rather confused by this attempt to make NEA fit into some kind of a network protection mechanism. I keep hearing that NEA is *one* of a suite of protocols that may be used for protecting networks. Let's dig a bit deeper into what a network may employ as protection mechanisms in order to protect against all kinds of general threats. i) Access control mechanisms such as authentication and authorization (to ensure only valid endpoints are allowed on the network) ii) Ingress address filtering to prevent packets with topologically incorrect IP addresses from being injected into the network iii) VPNs to provide remote access to clients iv) Firewalls to provide advanced filtering mechanisms v) IDS/IPS to detect and prevent intrusions vi) Application level filtering where applicable (e.g., detecting and discarding email spam) If an application happens to be malware, it seems it would be unlikely stop these applications. How about: vi) Provide application level advisory information pertaining to available services. Points that seem to be missing are: vii) Notification of non-compliance. (Perhaps this could become a restatement of i.) viii) Time or sequence sensitive compliance certificates provided following a remediation process or service. Often bad behavior is detected, such as scanning or sending spam which may violate AUPs. These violations may trigger a requirement for the endpoint to use a service that offers remedies the endpoint might use. There could then be a time-sensitive certificate of compliance offered following completion of a check-list and an agreement to comply with the recommendations. Those that remain infected after remediation, or that ignore the AUPs and are again detected, may find this process a reason to correct the situation or their behavior, or the provider may wish to permanently disable the account. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Douglas Otis wrote: If an application happens to be malware, it seems it would be unlikely stop these applications. How about: vi) Provide application level advisory information pertaining to available services. Points that seem to be missing are: vii) Notification of non-compliance. (Perhaps this could become a restatement of i.) viii) Time or sequence sensitive compliance certificates provided following a remediation process or service. Often bad behavior is detected, such as scanning or sending spam which may violate AUPs. These violations may trigger a requirement for the endpoint to use a service that offers remedies the endpoint might use. There could then be a time-sensitive certificate of compliance offered following completion of a check-list and an agreement to comply with the recommendations. Those that remain infected after remediation, or that ignore the AUPs and are again detected, may find this process a reason to correct the situation or their behavior, or the provider may wish to permanently disable the account. Am I mistaken or is NEA intended to be a compliance check before a node is allowed onto the network? As such, observed behaviour and application abuse would seem to be issues that would be dealt with by other tools. NEA may be used to ensure certain applications are installed and some other characteristics of the node but actual behaviour may not be evident until such time as the node has joined the network and would be beyond the scope of detection by NEA IMHO. NEA may be used to assist in limiting the risk of such behaviour but that is about the extent of it that I see. My reading of the charter gives me the impression NEA is only intended for a specific task and some of what we have been discussing seems to extend well beyond the limited scope proposed. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
On Tue, 10 Oct 2006 17:10:50 -0700, Fleischman, Eric [EMAIL PROTECTED] wrote: I'm sorry to enter this fray, but I'd like to point out that while I respect Todd's request to know who is accusing him and why, the rest of us don't need to be copied that information. In fact, it is better that we aren't copied because to do so would be unfair to the complainer(s). Discipline is a difficult task to do fairly and because of this there are many advantages in respectfully permitting the protagonists to have privacy during key parts of the process. As much as I've sparred with Glassey in the past (I suspended him from a WG mailing list, and was the target of an appeal to the IESG by him), I think he's right in this case. In my opinion, any sort of disciplinary action needs to be *perceived* as fair. That may not be as much of an issue here -- the public record of Todd's postings is appallingly clear -- but I think we do need to follow due process. I do agree that the Sergeants-at-Arms can act on their own volition, but if they do they should say so; that gives the community grounds to judge their behavior. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Vidya: I'm not sure that the charter actually needs to get into the modes at all - I'm guessing what happens after NEA (i.e., what is done with the results from NEA) has zero impact on any work being done in NEA itself. So, why not simply state something like Once NEA is conducted on an endpoint, the results may be used by an organization in accordance with any policies of the organization itself.? Discussions with the IAB and IESG prior to external review lead to the addition of the modes discussion. The point is that some networks will demand compliance to grant full access, and other networks will simply notify that host that they are not in compliance. A host my not want to change the configuration to gain compliance. That is acceptable in the second case, but not the first. Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints and complainers (Re: [Nea] WG Review: Network Endpoint Assessment (nea))
Just FTR (and changing the subject, since this is not about NEA at all): I agree with the principle that the sergeants-at-arms are obliged to make up their own minds about whether or not a posting is inappropriate, and that they are responsible for their own decisions. Complaints are a means of calling their attention to a situation, nothing more. An IETF participant should not have to suffer rants and threats from a suspended person in his private email inbox just because he commented to a sergeant-at-arms that he found the person's postings offensive. I think the sergeants-at-arms have made the right call. I agree with everything Harald says here. Analogies to court situations and the notion of facing your accuser are IMO entirely inappropriate. A better analogy is to the many mechansisms that exist in various other contexts for providing tips, suggestions, recommendations and compliants. In many of these cases anonymity is not only allowed, it is required. I don't think this is a case where anonymity is absolutely required, but it is definitely beneficial. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
From: Steven M. Bellovin [EMAIL PROTECTED] it is better that we aren't copied because to do so would be unfair to the complainer(s). As much as I've sparred with Glassey in the past ... I think he's right in this case. In my opinion, any sort of disciplinary action needs to be *perceived* as fair. ... I think we do need to follow due process. I'm going to disagree with you on this. My reasoning is that the decision of whether or not to suspend should be based almost entirely on the target person's posts, so the identity (and, indeed, the number) of people complaining is basically irrelevant. The whole concept of facing your accuser came about because the accusers usually made factual claims (I saw Joe steal Frank's car). Traditionally, people wanted to be able to weigh the truthfulness of such claims by observing the person making the assertion, and observing their response to questioning. In addition, the target might know of some grudge that led the accuser to make a false accusation. In this case, however, there is absolutely no probative value coming from knowing *who* complained. To put it another way, I would hope if several people complained about some reasonable post, the SaA(s) would independently review the post, and if they thought it was reasonable, would take no action, the number or identity of the complainers notwithstanding. The issue is not who complained - the issue is the content of the posts - and that's all. Indeed, any miniscule probative value in knowing who complained is entire outweighed, IMO, by the possibility that making their identities public would result in a campaign of harrassment against them. And no, I was not one of the people who complained privately. I do agree that the Sergeants-at-Arms can act on their own volition, but if they do they should say so I have no probem with the SaA(s) disclosing whether or not they acted entirely on their own bat, in response to complaints, or both. In addition, I have no problem with them disclosing the number (if any) of complainters. However, I strenuously oppose making the names public, because the potential harm in that (possibility for harassment, and also the possibility that less-forthcoming people will sit on their hands rather than complain, if their names have to be made public) far outweighs any possible value in in mking them public. Indeed, it turns out that most police departments actually have anonymous tip lines, for precisely these reasons (and others). If the community decides to do elsewise, I offer myself up as an anonymizing agent for any complaints to the SaA(s); i.e. I will forward any complaints sent to me, as if they were my own, after removing the identity of the former. If I can recruit a few other people to do the same, that will suffice to avoid any issue with one person not being able to complain more than once. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
I run a very closed network, ports are closed and not opened unless there is a validated request, external drives are disabled etc etc. A contractor comes in with a notebook and needs to work on some files located on our internal secure network. A trusted staff member rings in with the request to open a specified port. The port is opened and the contractor hooks up the laptop to it. NEA does it's thing and if the laptop doesn't match the requirements of the internal network policy it is directed to a sandbox network for remediation. If the laptop does meet the policy then it allowed onto the internal network. What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? The first case is certainly current practice, and the second one could arrive any day. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
- Original Message - From: Steven M. Bellovin [EMAIL PROTECTED] To: Fleischman, Eric [EMAIL PROTECTED] Cc: todd glassey [EMAIL PROTECTED]; [EMAIL PROTECTED]; ietf@ietf.org Sent: Wednesday, October 11, 2006 7:09 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) On Tue, 10 Oct 2006 17:10:50 -0700, Fleischman, Eric [EMAIL PROTECTED] wrote: I'm sorry to enter this fray, but I'd like to point out that while I respect Todd's request to know who is accusing him and why, the rest of us don't need to be copied that information. In fact, it is better that we aren't copied because to do so would be unfair to the complainer(s). Eric - then talk to the SOA's - they posted the commentary as public notice - I just responded to it. Discipline is a difficult task to do fairly and because of this there are many advantages in respectfully permitting the protagonists to have privacy during key parts of the process. As much as I've sparred with Glassey in the past (I suspended him from a WG mailing list, and was the target of an appeal to the IESG by him), I think he's right in this case. Scary thought that eh? In my opinion, any sort of disciplinary action needs to be *perceived* as fair. That may not be as much of an issue here -- the public record of Todd's postings is appallingly clear -- but I think we do need to follow due process. I do agree that the Sergeants-at-Arms can act on their own volition, Cool - when was this capability specifically placed into the IETF's Charter or the Job Description of the SOA? Who is accountable for that SOA's actions (including the party that appoints them?) And can they create policy to 'fit the moment' and if so how? but if they do they should say so; that gives the community grounds to judge their behavior. And it also provides specific recourse in Courts against the IETF and that individual and their Sponser. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
At 7:55 PM +1000 10/11/06, Darryl \(Dassa\) Lynch wrote: I run a very closed network, ports are closed and not opened unless there is a validated request, external drives are disabled etc etc. A contractor comes in with a notebook and needs to work on some files located on our internal secure network. A trusted staff member rings in with the request to open a specified port. The port is opened and the contractor hooks up the laptop to it. NEA does it's thing and if the laptop doesn't match the requirements of the internal network policy it is directed to a sandbox network for remediation. One of the points that has been made here several times is that the rosy promise of a sandbox for remediation has a number of thorns, even in the case where a posture assessment method has identified a potential issue. As it stands, there are commonly multiple ways to work around a vulnerability, including base-levels upgrades (from OS Foo v3 to v4) specific patches (either to the OS or to the application), and, in some cases, configurations (turning off functionality BAR). Assessing those is difficult; offering remediation is trickier yet, especially when one or more of the systems which may need remediation may not even been active at the time of attachment. As I have expressed before, I have serious doubts that the standardized parameters will be sufficient to do any reasonable assessment, and the same carries through in spades for remediation, since that involves a check that none of the remediations has already been applied. Maintaining a valid, *current* set of patches, OS upgrades, and the like for remediation is going to be a very big task; managing the licensing on it a nasty problem; and handling the potential liability of applying the *wrong* remediation a nightmare. Handling unknown states (even for those running recognized assessors) is an even more problematic issue, but you may not care that some folks run development drops of OSes and applications, since you can always remediate them by offering a downgrade. In your example, the contractor presumably also agrees to your mucking with their laptop configuration as part of the contract, but the number of cases in which this is going to be wise is clearly a subset of all cases and it may be a tiny subset. If I came into your network and offered to work with you, my corporate IT folks would be upset if I allowed you to do any of the updates discussed above, so the sandbox is effectively a denial of network access. That's a policy decision you are welcome to make (it's your network), but it's a complex and risky way to make it. I continue to think that the core of this work (passing an opaque string prior to attachment) has some benefits snip Just another tool to give network administrators information and systems they can use to ensure the majority of users get their requirements met in a reasonable and timely manner. And I believe others agree with your tool in the toolkit view. But if you advertise a saw as a hammer, someone is going to get cut. regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Hi Darryl, Your email indicates that you would: a) somehow require that a visitor's laptop run an NEA client, b) expect the device to support PAs that the server requires to be checked, and c) trust data coming out of it, rather than treat that endpoint as an unknown endpoint and do IDS/IPS in the network. Other than finding this a rather bizzarre trust model, I have to say that there will be a very small set of such endpoints where the owner of that endpoint is going to be thrilled to allow you to place such clients on his/her device and perform updates on it. In short, this is exactly the type of endpoint I wouldn't imagine NEA being useful for! Vidya -Original Message- From: Darryl (Dassa) Lynch [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 2:56 AM To: Narayanan, Vidya; ietf@ietf.org; [EMAIL PROTECTED] Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Narayanan, Vidya wrote: SNIP I continue to remain puzzled on the above points! Hello Vidya Perhaps if I put forward an example of how NEA may benefit me it would go some way to clear the puzzle. I run a very closed network, ports are closed and not opened unless there is a validated request, external drives are disabled etc etc. A contractor comes in with a notebook and needs to work on some files located on our internal secure network. A trusted staff member rings in with the request to open a specified port. The port is opened and the contractor hooks up the laptop to it. NEA does it's thing and if the laptop doesn't match the requirements of the internal network policy it is directed to a sandbox network for remediation. If the laptop does meet the policy then it allowed onto the internal network. I have not had to physically interface with the laptop or needed to allow it onto the internal network before some basic checks have been carried out. If the laptop met the policy requirements it was quickly allowed into the internal network and the contractor hasn't had to prove to me their device could be trusted except through automated means using NEA. If I wish, I can run some more checks as the laptop joins the internal network including additional authentication and other hoops to ensure the system hasn't lied through NEA. Really I see NEA as providing additional information to a network administrator so they automate more decisions on the network. In the above situation, if I felt NEA provided all the information I needed I'd leave ports open and be reasonably confident there was little risk in doing so as unknown systems would be directed to the sandbox network if necessary and if a lying system was able to make it to the internal network my normal protection/security measures would catch it out or warn me of the possibility within a reasonable time. Just another tool to give network administrators information and systems they can use to ensure the majority of users get their requirements met in a reasonable and timely manner. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Russ - I agree that something like a global NEA is necessary - just not that a new protocol is necessary to implement it. So let me ask... So then why not pass a new configuration mode model with SNMP - the point is that while the idea of some agent that could actually collect these separate logs and service records from the various 'aspects of compliance' built into the operating models of the system in question, is no new one. Tripwire's does this already. COPS and FREMONT can be made to with CRON and their configuration files. SNORT, AIDE, Heck they can even use SysLogNG as the transport for their log data which might also make sense as an addition... Or SCP/SFTP if they wanted to. The point is that while NEA is a good collective idea at the altitude the idea was hatched at, there are already things that do the NEA component functions today, and that can be aggregated together into a homogeneous utility environment without redesigning the wheel again. I don't dispute that the end goal of what the Creator's of the NEA idea wanted to accomplish is not good. It is clearly. But the issue is whether its necessary to have in the form they have proposed so far when other very similar and more widely deployed transports exist for the Inter-Nodal Communications Model that NEA purports to want to create. Again - SNMP and Syslog/SysLogNG can do allot of this already. Why not just add an Node-Integrity Reporting Process to either of them. From an Audit Perspective this would be a powerful addition to the SysLog protocols since it would better anchor them Just my 35c. Todd Glassey - Original Message - From: Russ Housley [EMAIL PROTECTED] To: Narayanan, Vidya [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org Sent: Wednesday, October 11, 2006 7:18 AM Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Vidya: I'm not sure that the charter actually needs to get into the modes at all - I'm guessing what happens after NEA (i.e., what is done with the results from NEA) has zero impact on any work being done in NEA itself. So, why not simply state something like Once NEA is conducted on an endpoint, the results may be used by an organization in accordance with any policies of the organization itself.? Discussions with the IAB and IESG prior to external review lead to the addition of the modes discussion. The point is that some networks will demand compliance to grant full access, and other networks will simply notify that host that they are not in compliance. A host my not want to change the configuration to gain compliance. That is acceptable in the second case, but not the first. Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Hi Russ, -Original Message- From: Russ Housley [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 11, 2006 7:19 AM To: Narayanan, Vidya Cc: [EMAIL PROTECTED]; iesg@ietf.org; ietf@ietf.org Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Vidya: I'm not sure that the charter actually needs to get into the modes at all - I'm guessing what happens after NEA (i.e., what is done with the results from NEA) has zero impact on any work being done in NEA itself. So, why not simply state something like Once NEA is conducted on an endpoint, the results may be used by an organization in accordance with any policies of the organization itself.? Discussions with the IAB and IESG prior to external review lead to the addition of the modes discussion. The point is that some networks will demand compliance to grant full access, and other networks will simply notify that host that they are not in compliance. A host my not want to change the configuration to gain compliance. That is acceptable in the second case, but not the first. I don't disagree with the above. But, I was mainly wondering what impact any of these decisions may have on NEA itself? Aren't these just post-NEA actions? In general though, I have far less problems with this text than I do with the idea of NEA somehow protecting networks or NEA being performed on endpoints that is not owned by the organization performing NEA. Regards, Vidya Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Vidya, Thanks for your response. I think we may be getting closer to understanding each other's perspectives. That's a good thing. Let me respond to your comments inline below. I hope you won't mind if I clip a bit since this thread is starting to get long. Vidya Narayanan wrote: A. Any network is exposed to threats from lying endpoints, compromised endpoints and unknown vulnerabilities even on NEA-compliant endpoints. B. A network needs to be protected against such generic threats (as listed in A). Agreed. There are plenty of other threats but that's enough for now. I am rather confused by this attempt to make NEA fit into some kind of a network protection mechanism. I keep hearing that NEA is *one* of a suite of protocols that may be used for protecting networks. Let's dig a bit deeper into what a network may employ as protection mechanisms in order to protect against all kinds of general threats. i) Access control mechanisms such as authentication and authorization (to ensure only valid endpoints are allowed on the network) ii) Ingress address filtering to prevent packets with topologically incorrect IP addresses from being injected into the network iii) VPNs to provide remote access to clients iv) Firewalls to provide advanced filtering mechanisms v) IDS/IPS to detect and prevent intrusions vi) Application level filtering where applicable (e.g., detecting and discarding email spam) A combination of the above (or the like) needs to be used to address the general threats mentioned above (in B, for e.g.). Given that, what does NEA bring to the network that isn't already provided by such mechanisms that need to be employed anyway? It is not like we can stop using some of these mechanisms if NEA is present, since the threats that NEA may protect against (from the network perspective) are a small subset of the general threats that a network operator must consider. And, when the general threats are addressed, any subset of those threats are also addressed. NEA is another network security tool. Like the others, it has some special advantages but does not remove the need for the others. What does NEA provide that isn't provided by the others? NEA can 1) identify unhealthy endpoints (vulnerable or infected) 2) quarantine unhealthy endpoints before they can infect others or become infected (optionally) 3) repair unhealthy endpoints (optionally) Yes, NEA cannot provide all these functions itself. NEA provides a framework for passing messages about endpoint health. Other security products use that framework to collect, send, and validate specific posture attributes and then to send remediation instructions and/or quarantine unhealthy endpoints. The effectiveness of NEA is tied to the type of endpoint (i.e., truthful, compliant endpoints with known vulnerabilities). A network, OTOH, needs mechanisms that protect against all kinds of endpoints. I fail to understand why a particular category of endpoints that NEA addresses is not viewed as a subset of the general category of all endpoints. With the aid of technology for detecting lying endpoints, NEA can also handle that class of endpoints. But I agree that NEA will probably never apply to every endpoint on the network. For endpoints that support NEA, the network operator can provide better security. For endpoints that don't support NEA, it will be status quo. Steve Hanna wrote: In the context of an overall security program and when combined with other security technologies, NEA can help protect networks. Let me list the ways. First, NEA can help improve the security of cooperating, truthful endpoints. How is this network protection? As you state above, it is about improving the security of co-operating, truthful *endpoints*. Network security is improved because fewer cooperating, truthful endpoints turn into uncooperative, infected endpoints that then flood the network with attacks. Second, NEA can be used with technology for detecting lying endpoints. This prevents compromised systems from lying to gain access to the network, thus providing a huge improvement in network security. Once again, given that a network operator must really protect against many generic threats, what kind of improvement is NEA bringing to the security of the network? See my comments above. Third, endpoints that don't initially participate in NEA protocols can be quarantined for further examination with an external vulnerability scanner or a dynamically downloaded NEA client. Again, this is not part of the proposed NEA WG charter but it is another example of ways that NEA can be used with other security technologies to improve network security. I'm confused by the above - what is the role of NEA here? I'm pointing out that endpoints that don't initially participate in NEA protocols can be quarantined and directed to a web page where they can run a dynamically downloaded
Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
In the end, I believe all NEA can do is help good hosts stay good. Bad hosts will stay bad, and may or may not be identifyable as such. Still, the former ain't nothing. But I agree with Ted at least in part that a standardization effort for the content within NEA is challenging. I do not think the licensing issues are quite so severe, however. If people understand the limits of NEA, then the liability should be a solvable problem, but then I'm really so not a lawyer. Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Brian E Carpenter wrote: I run a very closed network, ports are closed and not opened unless there is a validated request, external drives are disabled etc etc. A contractor comes in with a notebook and needs to work on some files located on our internal secure network. A trusted staff member rings in with the request to open a specified port. The port is opened and the contractor hooks up the laptop to it. NEA does it's thing and if the laptop doesn't match the requirements of the internal network policy it is directed to a sandbox network for remediation. If the laptop does meet the policy then it allowed onto the internal network. What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? The first case is certainly current practice, and the second one could arrive any day. Hello Brian I would be monitoring for unusual behaviour on the network and would be warned if the laptop started to behave in ways not expected. NEA would only save time in getting the system onto the network as instead of physically inspecting it I'd be relying on automated means to judge compliance. It would be an acceptable risk. The risk of someone wishing to hack in or being infected with a virus as you describe is low. I'd mainly be using NEA to assist in those situations where the trust isn't total but there isn't harmful intent. If you know of a system that provides total protection, is easy for users to perform their duties and doesn't have me or IT staff doing physical checks I'd be more than willing to look at it. Let's face it, there will always be a risk of someone getting around any informational or protection mechanism put into play, we all have to judge that risk and set up networks accordingly. If we really want to be secure we wouldn't allow any ad hoc connections at all. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Hello Ted Comments inline as appropriate. Ted Hardie wrote: At 7:55 PM +1000 10/11/06, Darryl \(Dassa\) Lynch wrote: I run a very closed network, ports are closed and not opened unless there is a validated request, external drives are disabled etc etc. A contractor comes in with a notebook and needs to work on some files located on our internal secure network. A trusted staff member rings in with the request to open a specified port. The port is opened and the contractor hooks up the laptop to it. NEA does it's thing and if the laptop doesn't match the requirements of the internal network policy it is directed to a sandbox network for remediation. One of the points that has been made here several times is that the rosy promise of a sandbox for remediation has a number of thorns, even in the case where a posture assessment method has identified a potential issue. As it stands, there are commonly multiple ways to work around a vulnerability, including base-levels upgrades (from OS Foo v3 to v4) specific patches (either to the OS or to the application), and, in some cases, configurations (turning off functionality BAR). Assessing those is difficult; offering remediation is trickier yet, especially when one or more of the systems which may need remediation may not even been active at the time of attachment. As I have expressed before, I have serious doubts that the standardized parameters will be sufficient to do any reasonable assessment, and the same carries through in spades for remediation, since that involves a check that none of the remediations has already been applied. Very true, any remediation is difficult. It may be there will be options provided so once a system fails to meet NEA compliance they are offered a number of options instead of remediation, perhaps limited access, no access or intervention by IT staff, all this is beyond the scope of NEA at this stage IMHO. Maintaining a valid, *current* set of patches, OS upgrades, and the like for remediation is going to be a very big task; managing the licensing on it a nasty problem; and handling the potential liability of applying the *wrong* remediation a nightmare. Handling unknown states (even for those running recognized assessors) is an even more problematic issue, but you may not care that some folks run development drops of OSes and applications, since you can always remediate them by offering a downgrade. What is the difference to maintaining the network nodes already on the system. They all have to be maintained and kept in compliance already. NEA just provides some information on what may be needed. In your example, the contractor presumably also agrees to your mucking with their laptop configuration as part of the contract, but the number of cases in which this is going to be wise is clearly a subset of all cases and it may be a tiny subset. If I came into your network and offered to work with you, my corporate IT folks would be upset if I allowed you to do any of the updates discussed above, so the sandbox is effectively a denial of network access. That's a policy decision you are welcome to make (it's your network), but it's a complex and risky way to make it. If they don't agree to the network policy then alternatives would need to be available such as providing a trusted system for them to use. Hackers and theives wouldn't agree to abide by any policy in place but that doesn't mean I have to provide methods to make their life easier :). I continue to think that the core of this work (passing an opaque string prior to attachment) has some benefits I don't disagree. snip Just another tool to give network administrators information and systems they can use to ensure the majority of users get their requirements met in a reasonable and timely manner. And I believe others agree with your tool in the toolkit view. But if you advertise a saw as a hammer, someone is going to get cut. Most accidents occur in the home. People do have to take some responsibility for themselves. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Hi Vidya Comments inline as appropriate. Narayanan, Vidya wrote: Your email indicates that you would: a) somehow require that a visitor's laptop run an NEA client, b) expect the device to support PAs that the server requires to be checked, and c) trust data coming out of it, rather than treat that endpoint as an unknown endpoint and do IDS/IPS in the network. You are limiting my options to a small subset of what I would have available. I may sandbox systems that don't have an NEA client and are unwilling to install one, they would be treated as an unknown node and given very limited access, they wouldn't be allowed onto the trusted network for instance. I would expect some information to be available which I would then be able to check against my policy. I would assume a limited amount of trust but would continue to have other mechanisms in place to be informed where that limited trust has been abused. Other than finding this a rather bizzarre trust model, I have to say that there will be a very small set of such endpoints where the owner of that endpoint is going to be thrilled to allow you to place such clients on his/her device and perform updates on it. If they wish to join my network they have to abide by the policies I have in place, they don't like it, they don't get to play. In short, this is exactly the type of endpoint I wouldn't imagine NEA being useful for! NEA is a means to automate the information gathering about this endpoint, if they don't agree to the policies, they will have options to. If a person or device doesn't agree with the policies in place, it doesn't mean I should still provide full access for them. Risk management will dictate what will or will not be allowed. Darryl (Dassa) Lynch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
I completely agree with Noel on every detail of these comments. And, no, I was not one of the complainers either. :-) -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- Sent: Wednesday, October 11, 2006 11:26 AM -- To: ietf@ietf.org -- Cc: [EMAIL PROTECTED] -- Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) -- -- From: Steven M. Bellovin [EMAIL PROTECTED] -- -- it is better that we aren't copied because to do so -- would be unfair to -- the complainer(s). -- -- As much as I've sparred with Glassey in the past ... -- I think he's right -- in this case. In my opinion, any sort of disciplinary -- action needs to -- be *perceived* as fair. ... I think we do need to -- follow due process. -- -- I'm going to disagree with you on this. My reasoning is -- that the decision of -- whether or not to suspend should be based almost entirely -- on the target -- person's posts, so the identity (and, indeed, the number) of people -- complaining is basically irrelevant. -- -- The whole concept of facing your accuser came about -- because the accusers -- usually made factual claims (I saw Joe steal Frank's -- car). Traditionally, -- people wanted to be able to weigh the truthfulness of such claims by -- observing the person making the assertion, and observing -- their response to -- questioning. In addition, the target might know of some -- grudge that led the -- accuser to make a false accusation. In this case, however, there is -- absolutely no probative value coming from knowing *who* complained. -- -- To put it another way, I would hope if several people -- complained about some -- reasonable post, the SaA(s) would independently review the -- post, and if they -- thought it was reasonable, would take no action, the number -- or identity of -- the complainers notwithstanding. The issue is not who -- complained - the issue -- is the content of the posts - and that's all. -- -- Indeed, any miniscule probative value in knowing who -- complained is entire -- outweighed, IMO, by the possibility that making their -- identities public would -- result in a campaign of harrassment against them. -- -- And no, I was not one of the people who complained privately. -- -- -- I do agree that the Sergeants-at-Arms can act on -- their own volition, -- but if they do they should say so -- -- I have no probem with the SaA(s) disclosing whether or not -- they acted -- entirely on their own bat, in response to complaints, or -- both. In addition, I -- have no problem with them disclosing the number (if any) of -- complainters. -- -- However, I strenuously oppose making the names public, -- because the potential -- harm in that (possibility for harassment, and also the -- possibility that -- less-forthcoming people will sit on their hands rather than -- complain, if -- their names have to be made public) far outweighs any -- possible value in in -- mking them public. Indeed, it turns out that most police -- departments actually -- have anonymous tip lines, for precisely these reasons (and others). -- -- -- If the community decides to do elsewise, I offer myself up -- as an anonymizing -- agent for any complaints to the SaA(s); i.e. I will forward -- any complaints -- sent to me, as if they were my own, after removing the -- identity of the -- former. If I can recruit a few other people to do the same, -- that will suffice -- to avoid any issue with one person not being able to -- complain more than once. -- -- Noel -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Hey Ted - the more I thought about this post of yours the more it annoyed me. You see - when a WG chair doesn't want someone saying something in their WG and they control the number of players in that WG, they will always control the consensus such as it is. The point is that there is no where to permanently register a dissenting opinion in an effort or IETF program now that you claim that the charter for the IETF@IETF.ORG mailing list is restricted. The IETF needs IMHO one general list for everything that doesn't fall under the rubric/charter/umbrella of some WG and their list, and personally after NETWORK was shutdown I thought that this was it. Todd Glassey - Original Message - From: Theodore Tso [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 3:16 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) On Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote: So then Ted are you formally saying that it is inappropriate to discuss IETF operations or its processes on the IETF@IETF.ORG mailing list? If you have a specific and actionable suggestion regarding IETF direction, policy, meetings, and procedures, where there is not a more appropriate e-mail venue (such as the IPR wg list), then it is certainly, appropriate for the IETF list. Your recent postings, alas, have not met this test. The problem with the IPR working group is simply that Harald kicks people off for disagreeing with him or his very limited charter. He doesn't want to hear about expanding the charter or how these other issues fit into the IPR Working Group and in doing so he is violating my and others participatory rights as well as our First Amendment rights I believe too. First Amendment rights only apply when the US Government restricts speech. It does not apply anywhere else. In general, you have been making various legal claims without being a lawyer, and fairly wild ones which make it very clear that you don't know what you are talking about. For what it's worth, be advised that I know of know legally enforceable right that you might have towards participating in any IETF forum, and certainly if you persist in sounding like someone who does not know what they are talking about, no one is required to listen to you, either --- and more and more people may in fact decide that it is wise for them to exercise their right to ignore you. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Todd, I've received several complains from people that think that you are crossing the limit again and being off-topic with this thread and I seriously agree with them. Consequently I warn you. If you keep going on this, I will apply a new ban (two weeks, as it will be your second one in a very short period of time). Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 11:37:49 -0700 Para: Theodore Tso [EMAIL PROTECTED] CC: [EMAIL PROTECTED] [EMAIL PROTECTED], ietf@ietf.org Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Hey Ted - the more I thought about this post of yours the more it annoyed me. You see - when a WG chair doesn't want someone saying something in their WG and they control the number of players in that WG, they will always control the consensus such as it is. The point is that there is no where to permanently register a dissenting opinion in an effort or IETF program now that you claim that the charter for the IETF@IETF.ORG mailing list is restricted. The IETF needs IMHO one general list for everything that doesn't fall under the rubric/charter/umbrella of some WG and their list, and personally after NETWORK was shutdown I thought that this was it. Todd Glassey - Original Message - From: Theodore Tso [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 3:16 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) On Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote: So then Ted are you formally saying that it is inappropriate to discuss IETF operations or its processes on the IETF@IETF.ORG mailing list? If you have a specific and actionable suggestion regarding IETF direction, policy, meetings, and procedures, where there is not a more appropriate e-mail venue (such as the IPR wg list), then it is certainly, appropriate for the IETF list. Your recent postings, alas, have not met this test. The problem with the IPR working group is simply that Harald kicks people off for disagreeing with him or his very limited charter. He doesn't want to hear about expanding the charter or how these other issues fit into the IPR Working Group and in doing so he is violating my and others participatory rights as well as our First Amendment rights I believe too. First Amendment rights only apply when the US Government restricts speech. It does not apply anywhere else. In general, you have been making various legal claims without being a lawyer, and fairly wild ones which make it very clear that you don't know what you are talking about. For what it's worth, be advised that I know of know legally enforceable right that you might have towards participating in any IETF forum, and certainly if you persist in sounding like someone who does not know what they are talking about, no one is required to listen to you, either --- and more and more people may in fact decide that it is wise for them to exercise their right to ignore you. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Who filed the complaints? if you are accusing me of something I have the right to know of what I am accused and by whom. Todd Glassey - Original Message - From: JORDI PALET MARTINEZ [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; Cc: [EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 12:34 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Todd, I've received several complains from people that think that you are crossing the limit again and being off-topic with this thread and I seriously agree with them. Consequently I warn you. If you keep going on this, I will apply a new ban (two weeks, as it will be your second one in a very short period of time). Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 11:37:49 -0700 Para: Theodore Tso [EMAIL PROTECTED] CC: [EMAIL PROTECTED] [EMAIL PROTECTED], ietf@ietf.org Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Hey Ted - the more I thought about this post of yours the more it annoyed me. You see - when a WG chair doesn't want someone saying something in their WG and they control the number of players in that WG, they will always control the consensus such as it is. The point is that there is no where to permanently register a dissenting opinion in an effort or IETF program now that you claim that the charter for the IETF@IETF.ORG mailing list is restricted. The IETF needs IMHO one general list for everything that doesn't fall under the rubric/charter/umbrella of some WG and their list, and personally after NETWORK was shutdown I thought that this was it. Todd Glassey - Original Message - From: Theodore Tso [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 3:16 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) On Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote: So then Ted are you formally saying that it is inappropriate to discuss IETF operations or its processes on the IETF@IETF.ORG mailing list? If you have a specific and actionable suggestion regarding IETF direction, policy, meetings, and procedures, where there is not a more appropriate e-mail venue (such as the IPR wg list), then it is certainly, appropriate for the IETF list. Your recent postings, alas, have not met this test. The problem with the IPR working group is simply that Harald kicks people off for disagreeing with him or his very limited charter. He doesn't want to hear about expanding the charter or how these other issues fit into the IPR Working Group and in doing so he is violating my and others participatory rights as well as our First Amendment rights I believe too. First Amendment rights only apply when the US Government restricts speech. It does not apply anywhere else. In general, you have been making various legal claims without being a lawyer, and fairly wild ones which make it very clear that you don't know what you are talking about. For what it's worth, be advised that I know of know legally enforceable right that you might have towards participating in any IETF forum, and certainly if you persist in sounding like someone who does not know what they are talking about, no one is required to listen to you, either --- and more and more people may in fact decide that it is wise for them to exercise their right to ignore you. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Network Endpoint Assessment (nea)
I have seen a lot of discussion about whether NEA provides network protection. In fact, it has been suggested that the charter be revised to say NEA must not be considered a protection mechanism for networks. I don't agree. Let's start by examining this concept of network protection. It's an awfully broad concept. No single security technology can provide total protection for a network against all attacks. Instead, a careful threat analysis must be done and layered countermeasures put in place: firewalls, malware scanning, intrusion detection and prevention, strong authentication and authorization, strong encryption for data at rest and in transit, user education, etc. In the context of an overall security program and when combined with other security technologies, NEA can help protect networks. Let me list the ways. First, NEA can help improve the security of cooperating, truthful endpoints. When a cooperating, truthful endpoint connects to the network, its health can be checked and any problems fixed before it can come under attack. This helps protect networks by keeping endpoints healthy so that fewer endpoints become infected and potentially impact the network through port scanning and other misbehavior. The protection provided by NEA alone is not absolute. Healthy endpoints can be vulnerable to a zero day attack. And NEA on its own provides no protection against lying endpoints and no protection against hosts that don't participate in NEA protocols. But it's a lot better than today's situation where some endpoints are completely unprotected with patches or anti-virus software. Second, NEA can be used with technology for detecting lying endpoints. This prevents compromised systems from lying to gain access to the network, thus providing a huge improvement in network security. I recognize that technology for detecting lying endpoints is out of scope for the NEA effort but we shouldn't pretend that it doesn't exist. Without NEA or similar protocols, it will be hard to integrate lying endpoint detection systems into network access control. That's why the NEA BOF in Montreal agreed to include language in the charter saying that the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints. Third, endpoints that don't initially participate in NEA protocols can be quarantined for further examination with an external vulnerability scanner or a dynamically downloaded NEA client. Again, this is not part of the proposed NEA WG charter but it is another example of ways that NEA can be used with other security technologies to improve network security. To summarize, the NEA protocols will increase network security on their own. When combined with other technologies, the increase in network security is much greater. But either way it is not accurate to say that NEA is not a protection mechanism for networks. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Todd, People got very irritated with this type of messages and actually even complain why I'm not more strict. I got at the time being already 3 new complains after this message and obviouly I don't need to justify to you who is complaining. Clearly you crossed the line once more, and it took you only a few seconds after getting my warning, so just instructed the secretariat to ban you for two weeks from now. And please, understand that I don't have anything personal, just fulfilling my mission. Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 12:42:30 -0700 Para: [EMAIL PROTECTED], ietf@ietf.org, Contreras, Jorge [EMAIL PROTECTED] Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Who filed the complaints? if you are accusing me of something I have the right to know of what I am accused and by whom. Todd Glassey - Original Message - From: JORDI PALET MARTINEZ [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; Cc: [EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 12:34 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Todd, I've received several complains from people that think that you are crossing the limit again and being off-topic with this thread and I seriously agree with them. Consequently I warn you. If you keep going on this, I will apply a new ban (two weeks, as it will be your second one in a very short period of time). Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 11:37:49 -0700 Para: Theodore Tso [EMAIL PROTECTED] CC: [EMAIL PROTECTED] [EMAIL PROTECTED], ietf@ietf.org Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Hey Ted - the more I thought about this post of yours the more it annoyed me. You see - when a WG chair doesn't want someone saying something in their WG and they control the number of players in that WG, they will always control the consensus such as it is. The point is that there is no where to permanently register a dissenting opinion in an effort or IETF program now that you claim that the charter for the IETF@IETF.ORG mailing list is restricted. The IETF needs IMHO one general list for everything that doesn't fall under the rubric/charter/umbrella of some WG and their list, and personally after NETWORK was shutdown I thought that this was it. Todd Glassey - Original Message - From: Theodore Tso [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 3:16 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) On Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote: So then Ted are you formally saying that it is inappropriate to discuss IETF operations or its processes on the IETF@IETF.ORG mailing list? If you have a specific and actionable suggestion regarding IETF direction, policy, meetings, and procedures, where there is not a more appropriate e-mail venue (such as the IPR wg list), then it is certainly, appropriate for the IETF list. Your recent postings, alas, have not met this test. The problem with the IPR working group is simply that Harald kicks people off for disagreeing with him or his very limited charter. He doesn't want to hear about expanding the charter or how these other issues fit into the IPR Working Group and in doing so he is violating my and others participatory rights as well as our First Amendment rights I believe too. First Amendment rights only apply when the US Government restricts speech. It does not apply anywhere else. In general, you have been making various legal claims without being a lawyer, and fairly wild ones which make it very clear that you don't know what you are talking about. For what it's worth, be advised that I know of know legally enforceable right that you might have towards participating in any IETF forum, and certainly if you persist in sounding like someone who does not know what they are talking about, no one is required to listen to you, either --- and more and more people may in fact decide that it is wise for them to exercise their right to ignore you. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Yes actually you do -how does anyone complained against know who is complaining or why? - if the complaints are not public then the oversight is not real - its a paper fiction - a lie in print. Speaking of lies in print this is why IETF complaints are addressed and penalties for them assessed before the appeal can be resolved - because the IETF's oversight policy and practice model is ineffective and setup to allow the IETF to exact whatever penalties it wants from individuals without the benefit of the appeal or the appeal process. So YES I want to know specifically who complained. Todd Glassey - Original Message - From: JORDI PALET MARTINEZ [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; ietf@ietf.org Sent: Tuesday, October 10, 2006 2:11 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Todd, People got very irritated with this type of messages and actually even complain why I'm not more strict. I got at the time being already 3 new complains after this message and obviouly I don't need to justify to you who is complaining. Clearly you crossed the line once more, and it took you only a few seconds after getting my warning, so just instructed the secretariat to ban you for two weeks from now. And please, understand that I don't have anything personal, just fulfilling my mission. Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 12:42:30 -0700 Para: [EMAIL PROTECTED], ietf@ietf.org, Contreras, Jorge [EMAIL PROTECTED] Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Who filed the complaints? if you are accusing me of something I have the right to know of what I am accused and by whom. Todd Glassey - Original Message - From: JORDI PALET MARTINEZ [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; Cc: [EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 12:34 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Todd, I've received several complains from people that think that you are crossing the limit again and being off-topic with this thread and I seriously agree with them. Consequently I warn you. If you keep going on this, I will apply a new ban (two weeks, as it will be your second one in a very short period of time). Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 11:37:49 -0700 Para: Theodore Tso [EMAIL PROTECTED] CC: [EMAIL PROTECTED] [EMAIL PROTECTED], ietf@ietf.org Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Hey Ted - the more I thought about this post of yours the more it annoyed me. You see - when a WG chair doesn't want someone saying something in their WG and they control the number of players in that WG, they will always control the consensus such as it is. The point is that there is no where to permanently register a dissenting opinion in an effort or IETF program now that you claim that the charter for the IETF@IETF.ORG mailing list is restricted. The IETF needs IMHO one general list for everything that doesn't fall under the rubric/charter/umbrella of some WG and their list, and personally after NETWORK was shutdown I thought that this was it. Todd Glassey - Original Message - From: Theodore Tso [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 3:16 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) On Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote: So then Ted are you formally saying that it is inappropriate to discuss IETF operations or its processes on the IETF@IETF.ORG mailing list? If you have a specific and actionable suggestion regarding IETF direction, policy, meetings, and procedures, where there is not a more appropriate e-mail venue (such as the IPR wg list), then it is certainly, appropriate for the IETF list. Your recent postings, alas, have not met this test. The problem with the IPR working group is simply that Harald kicks people off for disagreeing with him or his very limited charter. He doesn't want to hear about expanding the charter or how these other issues fit into the IPR Working Group and in doing so he is violating my and others participatory rights as well as our First Amendment rights I believe too. First Amendment rights only apply when the US Government restricts speech. It does not apply anywhere else. In general, you have been making various legal claims without being a lawyer, and fairly wild ones which make it very clear that you don't know what you are talking about. For what it's worth, be advised that I know of know legally enforceable right that you might
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
I'm sorry to enter this fray, but I'd like to point out that while I respect Todd's request to know who is accusing him and why, the rest of us don't need to be copied that information. In fact, it is better that we aren't copied because to do so would be unfair to the complainer(s). Discipline is a difficult task to do fairly and because of this there are many advantages in respectfully permitting the protagonists to have privacy during key parts of the process. -Original Message- From: todd glassey [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 4:51 PM To: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Yes actually you do -how does anyone complained against know who is complaining or why? - if the complaints are not public then the oversight is not real - its a paper fiction - a lie in print. Speaking of lies in print this is why IETF complaints are addressed and penalties for them assessed before the appeal can be resolved - because the IETF's oversight policy and practice model is ineffective and setup to allow the IETF to exact whatever penalties it wants from individuals without the benefit of the appeal or the appeal process. So YES I want to know specifically who complained. Todd Glassey - Original Message - From: JORDI PALET MARTINEZ [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; ietf@ietf.org Sent: Tuesday, October 10, 2006 2:11 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Todd, People got very irritated with this type of messages and actually even complain why I'm not more strict. I got at the time being already 3 new complains after this message and obviouly I don't need to justify to you who is complaining. Clearly you crossed the line once more, and it took you only a few seconds after getting my warning, so just instructed the secretariat to ban you for two weeks from now. And please, understand that I don't have anything personal, just fulfilling my mission. Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 12:42:30 -0700 Para: [EMAIL PROTECTED], ietf@ietf.org, Contreras, Jorge [EMAIL PROTECTED] Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Who filed the complaints? if you are accusing me of something I have the right to know of what I am accused and by whom. Todd Glassey - Original Message - From: JORDI PALET MARTINEZ [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; Cc: [EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 12:34 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Todd, I've received several complains from people that think that you are crossing the limit again and being off-topic with this thread and I seriously agree with them. Consequently I warn you. If you keep going on this, I will apply a new ban (two weeks, as it will be your second one in a very short period of time). Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 11:37:49 -0700 Para: Theodore Tso [EMAIL PROTECTED] CC: [EMAIL PROTECTED] [EMAIL PROTECTED], ietf@ietf.org Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Hey Ted - the more I thought about this post of yours the more it annoyed me. You see - when a WG chair doesn't want someone saying something in their WG and they control the number of players in that WG, they will always control the consensus such as it is. The point is that there is no where to permanently register a dissenting opinion in an effort or IETF program now that you claim that the charter for the IETF@IETF.ORG mailing list is restricted. The IETF needs IMHO one general list for everything that doesn't fall under the rubric/charter/umbrella of some WG and their list, and personally after NETWORK was shutdown I thought that this was it. Todd Glassey - Original Message - From: Theodore Tso [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 3:16 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) On Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote: So then Ted are you formally saying that it is inappropriate to discuss IETF operations or its processes on the IETF@IETF.ORG mailing list? If you have a specific and actionable suggestion regarding IETF direction, policy, meetings, and procedures, where there is not a more appropriate e-mail venue (such as the IPR wg list), then it is certainly, appropriate for the IETF list. Your recent postings, alas, have not met this test. The problem with the IPR working group is simply
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Hi Eric, I don't really agree with that. I've first the obligation to keep the privacy about any email received in private. Of course, I can always suggest that the people which complained in private speak up in the list, but I don't think that noise will help anyone. If there is a need to review my decision, the body in charge of that appeal will have the information about those complains, of course. If we as a community, feel that this should work in a different way, we probably need to document/update the process used by the sergeant-at-arms. Regards, Jordi De: Fleischman, Eric [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 17:10:50 -0700 Para: todd glassey [EMAIL PROTECTED], [EMAIL PROTECTED], ietf@ietf.org Conversación: [Nea] WG Review: Network Endpoint Assessment (nea) Asunto: RE: [Nea] WG Review: Network Endpoint Assessment (nea) I'm sorry to enter this fray, but I'd like to point out that while I respect Todd's request to know who is accusing him and why, the rest of us don't need to be copied that information. In fact, it is better that we aren't copied because to do so would be unfair to the complainer(s). Discipline is a difficult task to do fairly and because of this there are many advantages in respectfully permitting the protagonists to have privacy during key parts of the process. -Original Message- From: todd glassey [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 4:51 PM To: [EMAIL PROTECTED]; ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Yes actually you do -how does anyone complained against know who is complaining or why? - if the complaints are not public then the oversight is not real - its a paper fiction - a lie in print. Speaking of lies in print this is why IETF complaints are addressed and penalties for them assessed before the appeal can be resolved - because the IETF's oversight policy and practice model is ineffective and setup to allow the IETF to exact whatever penalties it wants from individuals without the benefit of the appeal or the appeal process. So YES I want to know specifically who complained. Todd Glassey - Original Message - From: JORDI PALET MARTINEZ [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; ietf@ietf.org Sent: Tuesday, October 10, 2006 2:11 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Todd, People got very irritated with this type of messages and actually even complain why I'm not more strict. I got at the time being already 3 new complains after this message and obviouly I don't need to justify to you who is complaining. Clearly you crossed the line once more, and it took you only a few seconds after getting my warning, so just instructed the secretariat to ban you for two weeks from now. And please, understand that I don't have anything personal, just fulfilling my mission. Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 12:42:30 -0700 Para: [EMAIL PROTECTED], ietf@ietf.org, Contreras, Jorge [EMAIL PROTECTED] Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Who filed the complaints? if you are accusing me of something I have the right to know of what I am accused and by whom. Todd Glassey - Original Message - From: JORDI PALET MARTINEZ [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; Cc: [EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 12:34 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Todd, I've received several complains from people that think that you are crossing the limit again and being off-topic with this thread and I seriously agree with them. Consequently I warn you. If you keep going on this, I will apply a new ban (two weeks, as it will be your second one in a very short period of time). Regards, Jordi, acting as IETF Sergeant-at-arms De: todd glassey [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 10 Oct 2006 11:37:49 -0700 Para: Theodore Tso [EMAIL PROTECTED] CC: [EMAIL PROTECTED] [EMAIL PROTECTED], ietf@ietf.org Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Hey Ted - the more I thought about this post of yours the more it annoyed me. You see - when a WG chair doesn't want someone saying something in their WG and they control the number of players in that WG, they will always control the consensus such as it is. The point is that there is no where to permanently register a dissenting opinion in an effort or IETF program now that you claim that the charter for the IETF@IETF.ORG mailing list is restricted. The IETF needs IMHO one general list for everything that doesn't fall under the rubric/charter/umbrella of some WG and their list, and personally after NETWORK was shutdown I
RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea)
Hi Steve, Let me start with a couple of fundamental points that have already been stated before. A. Any network is exposed to threats from lying endpoints, compromised endpoints and unknown vulnerabilities even on NEA-compliant endpoints. B. A network needs to be protected against such generic threats (as listed in A). I am rather confused by this attempt to make NEA fit into some kind of a network protection mechanism. I keep hearing that NEA is *one* of a suite of protocols that may be used for protecting networks. Let's dig a bit deeper into what a network may employ as protection mechanisms in order to protect against all kinds of general threats. i) Access control mechanisms such as authentication and authorization (to ensure only valid endpoints are allowed on the network) ii) Ingress address filtering to prevent packets with topologically incorrect IP addresses from being injected into the network iii) VPNs to provide remote access to clients iv) Firewalls to provide advanced filtering mechanisms v) IDS/IPS to detect and prevent intrusions vi) Application level filtering where applicable (e.g., detecting and discarding email spam) A combination of the above (or the like) needs to be used to address the general threats mentioned above (in B, for e.g.). Given that, what does NEA bring to the network that isn't already provided by such mechanisms that need to be employed anyway? It is not like we can stop using some of these mechanisms if NEA is present, since the threats that NEA may protect against (from the network perspective) are a small subset of the general threats that a network operator must consider. And, when the general threats are addressed, any subset of those threats are also addressed. The effectiveness of NEA is tied to the type of endpoint (i.e., truthful, compliant endpoints with known vulnerabilities). A network, OTOH, needs mechanisms that protect against all kinds of endpoints. I fail to understand why a particular category of endpoints that NEA addresses is not viewed as a subset of the general category of all endpoints. Some further comments inline. -Original Message- From: Stephen Hanna [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 10, 2006 1:30 PM To: ietf@ietf.org; [EMAIL PROTECTED]; iesg@ietf.org Subject: [Nea] Re: WG Review: Network Endpoint Assessment (nea) I have seen a lot of discussion about whether NEA provides network protection. In fact, it has been suggested that the charter be revised to say NEA must not be considered a protection mechanism for networks. I don't agree. Let's start by examining this concept of network protection. It's an awfully broad concept. No single security technology can provide total protection for a network against all attacks. Instead, a careful threat analysis must be done and layered countermeasures put in place: firewalls, malware scanning, intrusion detection and prevention, strong authentication and authorization, strong encryption for data at rest and in transit, user education, etc. In the context of an overall security program and when combined with other security technologies, NEA can help protect networks. Let me list the ways. First, NEA can help improve the security of cooperating, truthful endpoints. How is this network protection? As you state above, it is about improving the security of co-operating, truthful *endpoints*. When a cooperating, truthful endpoint connects to the network, its health can be checked and any problems fixed before it can come under attack. This helps protect networks by keeping endpoints healthy so that fewer endpoints become infected and potentially impact the network through port scanning and other misbehavior. The protection provided by NEA alone is not absolute. Healthy endpoints can be vulnerable to a zero day attack. And NEA on its own provides no protection against lying endpoints and no protection against hosts that don't participate in NEA protocols. But it's a lot better than today's situation where some endpoints are completely unprotected with patches or anti-virus software. Second, NEA can be used with technology for detecting lying endpoints. This prevents compromised systems from lying to gain access to the network, thus providing a huge improvement in network security. Once again, given that a network operator must really protect against many generic threats, what kind of improvement is NEA bringing to the security of the network? I recognize that technology for detecting lying endpoints is out of scope for the NEA effort but we shouldn't pretend that it doesn't exist. Without NEA or similar protocols, it will be hard to integrate lying endpoint detection systems into network access control. That's why the NEA BOF in Montreal agreed to include language in the charter saying that the protocols developed by the NEA WG must be designed to accommodate emerging
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
On Tue, Oct 10, 2006 at 07:45:48PM -0500, JORDI PALET MARTINEZ wrote: Hi Eric, I don't really agree with that. I've first the obligation to keep the privacy about any email received in private. Of course, I can always suggest that the people which complained in private speak up in the list, but I don't think that noise will help anyone. If there is a need to review my decision, the body in charge of that appeal will have the information about those complains, of course. Note that while we may use complaints from the community about whether or not postings are inappropriate, in the end it is up to the Sergeant-at-Arms about whether or not postings are appropriate and form a pattern of abuse. And the postings from the accused are publically available on mailing list archives, and can be judged on their own (dis-)merits. For that reason, I don't believe that there is any need to reveal private communications about complaints, since the in the end, the final determination is and can be made by the postings in isolation. That being said, we do periodically check in with the IETF Chair, who appointed us and has the power to dismiss us, whether or not in his opinion, we are using the appropriate trigger levels for enforcing violations of RFC 3005. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
WG Review: Network Endpoint Assessment (nea)
I have a very basic fear that this working group is getting chartered with a bunch of aims added by people who will not take on the task of doing the work. After private discussion with folks involved, my sense is that the very core of this work is a perceived need to be able to pass opaque strings between a host and the network prior to the host attaching. Those opaque strings are, essentially, the vendor-specific strings currently associated with posture assessment. The standard protocol carrying these strings would connect on the network side to a system that has plug-ins which understand the vendor-specific strings. With a charter that clarified that this was intended to assist the end systems with vulnerabilities prior to attachment because the network they are attaching to might be filled with danger, I think this work would get done reasonably quickly. (As a control mechanism to protect the network, I agree with the point made clearly by others that this is not appropriate). I am less sure of the task of standardizing attributes. I am not sure that the number of attributes which can be standardized will ever be high enough to be truly useful, and I am pretty sure that all of these will be already covered by vendor-specific attributes. Since there must be an assessor in place on the client for those few standardized attributes to be assessed and that assessor will likely already have these covered by vendor-specific attributes, in other words, we seem to be standardizing redundancy. On the network attachment side, it is possible, of course, that an offer of remediation could be made based on just the standard attributes, but it seems far more likely that it would be a two step process (assess standard attributes, then pass vendor-specific attributes to vendor plug-in). Again, if the vendor's attributes cover the standard attributes, then this is largely redundant and may add measurable latency; it seems far more likely that step one would simply be skipped if there were a vendor-specific string and an available plug-in. Since there has to be an assessor, the first seems very likely to me. If you don't have a vendor's plug-in, then I suppose there is some chance that you will trust and act based on the standard attributes, but the chance of getting the right remediation seems pretty slight in those circumstances. Especially when many vulnerabilities are a combination of conditions, (Browser version Foo on OS patch level Bar) that you could remediate by upgrading either one, checking for and acting on the attributes which could be standardized seems of very, very limited utility. Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
This is what I meant when I said that the charter is unclear and it must explicitly state that NEA is not meant as a protection mechanism of any sort for the network. I don't believe the Charter needs to delve into this at all. If some people see it as part of their protection mechanisms, so be it. Darryl (Dassa) Lynch The IETF has an obligation to truth in advertising so IMHO we should not claim protection that doesn't exist, even implicitly. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
The IETF has an obligation to WIPO and to the DMCA and well - so far its failed those pretty well I think. Todd Glassey - Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 2:07 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) This is what I meant when I said that the charter is unclear and it must explicitly state that NEA is not meant as a protection mechanism of any sort for the network. I don't believe the Charter needs to delve into this at all. If some people see it as part of their protection mechanisms, so be it. Darryl (Dassa) Lynch The IETF has an obligation to truth in advertising so IMHO we should not claim protection that doesn't exist, even implicitly. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Tood, Agreed, we should work to fix that. Fritz. - Original Message - From: todd glassey [EMAIL PROTECTED] To: Brian E Carpenter [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 7:17 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) The IETF has an obligation to WIPO and to the DMCA and well - so far its failed those pretty well I think. Todd Glassey - Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 2:07 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) This is what I meant when I said that the charter is unclear and it must explicitly state that NEA is not meant as a protection mechanism of any sort for the network. I don't believe the Charter needs to delve into this at all. If some people see it as part of their protection mechanisms, so be it. Darryl (Dassa) Lynch The IETF has an obligation to truth in advertising so IMHO we should not claim protection that doesn't exist, even implicitly. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Agreed, we should work to fix that. ... The IETF has an obligation to WIPO and to the DMCA ... I can only assume this was intended as some form of joke. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
The IETF has an obligation to WIPO and to the DMCA ... I can only assume this was intended as some form of joke. regardless of intent, it should be treated as such. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
No it wasn't Brian - the WIPO IP Framework calls for a set of protections for Industrial Designs which ALL of the work that happens here is controlled by right? Otherwise, do you formally want to make a declaration as the IETF's Chair that the IETF and the ISOC are immune from Global IP Law and can pretty much do anything they want. Todd Glassey - Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: ietf@ietf.org Cc: [EMAIL PROTECTED] Sent: Monday, October 09, 2006 7:31 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Agreed, we should work to fix that. ... The IETF has an obligation to WIPO and to the DMCA ... I can only assume this was intended as some form of joke. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Fritz this is a much bigger issue than ANYONE thinks at this time and its based on the idea that the WIPO standard says that the IETF MUST be doing Industrial Design IP Models, and it only does Copyright which is a violation of the WIPO IP protection framework and the treaties ALL of the Member States have signed. Interesting eh? Todd Glassey - Original Message - From: Fritz F. Saad [EMAIL PROTECTED] To: todd glassey [EMAIL PROTECTED]; Brian E Carpenter [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 6:58 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Tood, Agreed, we should work to fix that. Fritz. - Original Message - From: todd glassey [EMAIL PROTECTED] To: Brian E Carpenter [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 7:17 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) The IETF has an obligation to WIPO and to the DMCA and well - so far its failed those pretty well I think. Todd Glassey - Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Sent: Monday, October 09, 2006 2:07 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) This is what I meant when I said that the charter is unclear and it must explicitly state that NEA is not meant as a protection mechanism of any sort for the network. I don't believe the Charter needs to delve into this at all. If some people see it as part of their protection mechanisms, so be it. Darryl (Dassa) Lynch The IETF has an obligation to truth in advertising so IMHO we should not claim protection that doesn't exist, even implicitly. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Hi Darrly, snip It appears that the NEA charter is completely misleading to some people from what is stated in this email. As the NEA charter alludes to, NEA does nothing to protect against compromised devices. Also, as has been agreed, NEA is not a protection mechanism for the network - it is meant to be a protection mechanism for compliant, truthful and as yet uncompromised end hosts against known vulnerabilities. True the NEA doesn't do anything to protect against compromised devices but it does assist in limiting the known compromises on endpoint devices by being a mechanism for the checking and reporting on compliance to what ever network policy is in place including virus and patch levels. I'm not sure what you mean by known compromises - did you mean known vulnerabilities? If so, yes - I was not questioning the role of NEA in dealing with known vulnerabilities on truthful endpoints. The discussion was about using NEA as a protection mechanism for the network and that doesn't make sense to me and as I understand from Susan, that is not the intention of the charter either. As a network administrator I already deploy mechanisms for doing just this, but at a higher level than the NEA charter indicates. To me the difference is between being reactive or proactive. Compliance testing I already run occurs after an end node has joined the network, with NEA the possibility is for compliance checking before being allowed onto the network so isolation and immediate remediation is possible. Any network, in its own best interests, must assume that it has lying and compromised endpoints connecting to it and that there are unknown vulnerabilities on any NEA-compliant devices connecting to it. Any kind of protection that addresses these general threats that the network may be exposed to at any time will simply obviate the need for NEA from the network perspective. Reliance on one protection or reporting mechanism is not enough. We need a lot of varied tools to cover all the bases and minimise risk. This is repitition at this point - but, when a network has mechanisms to protect itself against lying endpoints and unknown vulnerabilites, that should cover protection against truthful ones with known vulnerabilities. Otherwise, the network is obviously not adequately protected against the broader set of threats. So, one would employ NEA in their networks to protect the end hosts attaching to the network, not the network itself. A network operator that thinks the network is getting any protection by employing NEA is clearly ignoring the obvious real threats that the network is exposed to at any time. No, NEA would just be one more tool used to improve overall security and minimise risk. It would be at a different level to the tools some of already deploy. This is what I meant when I said that the charter is unclear and it must explicitly state that NEA is not meant as a protection mechanism of any sort for the network. I don't believe the Charter needs to delve into this at all. If some people see it as part of their protection mechanisms, so be it. That is a terrible approach to take, given how misleading the charter obviously has been to many. The charter must be clear about what the WG is doing and what is out of scope. Vidya ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
