From nea-bounces@ietf.org Fri Dec 08 17:34:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsoIe-0000A0-QC; Fri, 08 Dec 2006 17:34:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsoId-00009c-He for nea@ietf.org; Fri, 08 Dec 2006 17:34:35 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsoIc-0002hb-Rk for nea@ietf.org; Fri, 08 Dec 2006 17:34:35 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 08 Dec 2006 14:31:23 -0800 X-IronPort-AV: i="4.09,515,1157353200"; d="scan'208"; a="622074012:sNHT56676080" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Dec 2006 17:34:33 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes from IETF 67 NEA WG meeting Thread-index: AccbGQhq2mrdVvFBSTWFV/jn7uI2ow== From: "Stephen Hanna" To: X-Spam-Score: 0.9 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Subject: [Nea] Draft minutes from IETF 67 NEA WG meeting X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Here are the draft minutes from the IETF 67 NEA WG meeting. If you have comments or corrections, please send them to me or to the NEA list ASAP. Thanks, Steve ---------- Minutes from NEA WG Meeting IETF 67 in San Diego, CA November 7, 2006, 3:20 PM - 5:20 PM Chaired by Steve Hanna and Susan Thomson Notes taken by Kaushik Narayanan, Mauricio Sanchez, and Paul Sangster These notes do not attempt to duplicate all the material in the slides. Instead, they provide a brief summary of that material and focus on comments and discussion (especially consensus checks). Steve Hanna welcomed people to the first meeting of the Network Endpoint Assessment Working Group. He reviewed logistical information about the group (email list, chairs, etc.). Blue sheets were distributed and minutes scribes found. No Jabber scribes were found. The following draft agenda was agreed to: 3:20 Circulate Blue Sheets, Identify Jabber & Minutes Scribes 3:25 Agenda Bashing 3:30 NEA Milestones 3:40 Discussion of Requirements I-D 5:10 Next Steps 5:20 Adjourn *NEA Milestones* Susan Thomson reviewed the milestones in the NEA charter. The current milestones are aimed at getting a NEA Requirements document submitted to the IESG by April 2007. Then we'll request AD approval to add milestones to standardize PA and PB. Susan Thomson reviewed roles and responsibilities within the NEA WG. A NEA Requirements design team will be formed to develop an initial draft of the NEA Requirements I-D and revise that I-D in response to WG rough consensus. Volunteers for the design team should contact Steve and Susan. A request for volunteers will be sent to the NEA list and we hope to have the design team launched within a couple of weeks. The goal for today is to discuss what the requirements I-D should contain and what use cases that requirements I-D should support. And we'll solicit volunteers for the design team. *Discussion of Requirements I-D* Susan reviewed a draft outline for the Requirements I-D (included in the slides) and asked if there are any obvious missing areas. There were no responses. Susan reviewed some basic terminology: endpoint and posture. An endpoint is any device that can be connected to a network and get an IP address. Posture is security-relevant configuration of an endpoint. Kaushik Narayanan: Isn't it true that posture can be a wide variety of information as long as it's used in a security policy? That makes it security relevant. Susan: Yes. Susan summarized the NEA problem statement: to assess the posture of an endpoint and determine whether it's in compliance with a security policy. Susan reviewed items that our charter says are in scope and others that are out of scope but must be accommodated. Susan presented the NEA Reference Model as described in the previously published problem statement. She suggested a refinement to the model to change the bottom layer to only perform posture transport since the PT protocol may be separate from that used in access control/enforcement. She asked if there are any comments or questions on this change. There were none. Steve Hanna took the mike to discuss use cases. The goal here is not to identify all possible use cases for NEA. It is to identify a minimal set of use cases that can be included in the Requirements I-D and that spans the problem space. We don't need to have a lot of information here, just enough to drive requirements definition. Paul Ferguson: How can we discuss requirements before defining the problem space? Steve: The problem space is described in the charter and will be described in more detail in the Requirements I-D. Steve listed several types of flows: - Initial assessment - triggered by network connection or service request - Re-assessment - triggered by NEA server or client (because of an event, timer, etc.) Steve listed and described several types of attributes: - Endpoint Data (client to server), by value or by reference - Compliance Policy (server to client) - Compliance Policy Evaluation Results (client to server) - Cryptographic Protocols (multiple round trips) - Compliance Result (server to client) - Remediation Instructions (server to client) Eric Rescorla: Is cryptographic protocol information considered an attribute? It's not helpful to have it defined as an attribute. Yaron Sheffer: I thought compliance policy was out of scope. How can you be including it in an attribute then? Steve: I'm not suggesting that attribute should be standardized. I'm just saying that's one attribute that can be sent. In fact, our charter states that the set of attributes to be standardized will be minimal. I don't expect policy would be in that set. Mani Mahalingam: Are enforcement points out of scope? Steve: Yes, our charter says so. Enforcement is out of scope. Other IETF WGs do enforcement protocols. Kaushik: Could completion of remediation be a trigger for reassessment? Steve: Yes, that would fall under the category of client triggered reassessment. Steve: I'll present a set of use cases that seem to span the problem=20 space as I understand it, driving all necessary requirements. See slides for details of those use cases. Brief summary here: John Smith - inventory collection of software on JS's endpoint at network join No enforcement. Jane Doe - send patch levels upon service request, upgrade advisory sent No enforcement. Colonel Mustard - constant monitoring while on network. Endpoint detects a=20 posture change so triggers re-assessment. Access is limited since the system isn't in compliance. Re-assessment occurs after remediation which allows access to be restored. Steve: Are there other use cases that must be addressed and which drive new PA, PB, or PT requirements? Bob Morgan: If the first use case is triggered by network connection, you should show the network access elements. And this would drive PT requirements since the endpoint may not have full network connectivity. Doug Otis: Most assessments involve a separate assessment server. Maybe that server should sign some credentials saying that the assessment has been completed. Then the NEA server can just look at those credentials. Steve: Does that drive any new requirements? Doug: Lots of trust issues are raised. The client needs to decide whether it trusts the remediation instructions. Steve: So that relates to the contents of the remediation instructions. Alan DeKok: I'm concerned about the defined architecture being overly limited as I can imagine other architectures for solving this problem. We could have remediation happen inside EAP-TLS, for instance. Steve: Using EAP to transport a lot of information such as remediation doesn't work well. EAP is not well suited for bulk data transfer and most wireless APs will time out after 25-200 round trips. However the point remains that there are other architectures for endpoint assessment. We need to stay within our charter, which talks about NEA Servers and NEA Clients. So there are some limitations to what's in scope. Khaja Ahmed: I wonder if a P2P use case would be helpful. And what about non-enterprise scenarios where an ISP checks the consumer system for them? Steve: I think that may violate an applicability limitation in our charter. Khaja: Am I right that PA might involve multiple round trips? Steve: Yes. There are use cases where that's required. Khaja: That could cause lots of latency due to many collectors causing lots of round trips. There must be a better way. Khaja: Compliance policy attributes (where the server tells the client what the policy is) doesn't sound like a good model. Steve: Any other comments? About any of this? None. So we'll take it to the list. Steve: I'm surprised at how quickly this has gone. We've come to the end of the slides that Susan and I had prepared. Fortunately, Paul Sangster has a presentation on the requirements I-D that was prepared last spring when we were a NEA BOF. Of course, these are somewhat dated and don't reflect the discussions around our chartering. But it's probably useful to discuss them, given that we have the time. Kapil Sood: We need a set of security requirements not just the functional requirements discussed so far. Steve: Yes, absolutely. We're going to have to do a complete security analysis of the entire system. We can derive security requirements from that. *Review of Previous Requirements I-D* Paul Sangster presented an overview of the old NEA BOF requirements I-D: draft-khosravi-nea-requirements-01.txt. See Paul's slides for details. Paul reviewed the outline and contributors for the spec. Then he described terminology: component, message, session, and dialog. Next, he summarized Common Requirements (common to PA, PB, and PT). 1. Capable of multi-message dialog Khaja: This shouldn't be a requirement. Requirements should be higher level, as they might be articulated by an IT administrator. This is more design. And I don't think this is a good idea. After further discussion, it was agreed that this should be discussed more later. 2. Allow server requests prior and after network access 3. Possible for client to initiate a posture re-evaluation request 4. Protection against active/passive attacks by intermediaries 5. PA and PB transport agnostic interfaces 6. Selection process prefer reuse of existing open standards 7. Scalable (many collectors and validators on multiple servers) Kaushik Narayanan: Requirements currently specify horizontal protocols between NEA client and NEA server, how about the vertical protocols on the client or server side? Paul: Vertical protocols are currently out-of-scope in the charter. Then Paul reviewed PA requirements: 1. Transport core attributes (vendor, version, operational status, ...) 2. Transport of vendor defined attributes 3. Validator request of particular client component's posture 4. Allow for multiple requests for posture information 5. Carry validator results and remediation instructions 6. Selection process prefer re-use of existing open standards for transport and attribute representation Bob Morgan: Whenever you get into schema (attribute formats, etc.), lots of issues come up. The client and server may need to agree on which attributes are supported by each. Doug Otis: We don't need any vendor-unique attributes if instead the server just asks for certificates proving the client has passed certain compliance checks. Vendor-specific attributes will cause lots of compatibility problems. Paul: Well, it would be nice to avoid those problems. Let's discuss your idea more. 7. SHOULD support expression of prior remediation state (e.g. time, server used.)=20 8. Capable of authentication, integrity and confidentiality of attributes, results and remediation instructions=20 Yaron Sheffer: Those properties can be provided by PB or PT. Paul: Actually, this requirement is specifically on PA. There are some use cases that drive that requirement. For instance, a validator that wants to know the collector is valid. Or a validatror and collector that want to keep their messages confidential from other components in the system (like the Posture Broker). We may not want to address those use cases but we should consider them. Yaron: PA should define the core attributes not just transport them. Steve: This requirements I-D is old and pre-dates IETF 66 where the group did agree to define the attributes. That's in our charter now and it will be done. Dave Nelson: When you say authentication of attributes, you really mean authentication of the component that sent the attributes, right? Paul: Right. The collector or validator. Khaja: Does this mean all collectors and validators must be able to protect their messages? Paul: No. This means that the protocol must support such protection. But the collector doesn't have to implement that feature. 9. SHOULD optimize transport of messages and minimize PB RTs PB Requirements 1. Capable of carrying the decision and (if present) remediation instructions 2. Carry naming for collectors and validators (used for message delivery) Naming should allow for dynamic registration 3. Multiplex message dialogs between multiple collectors and validators 4. Capable of authentication, integrity and confidentiality of messages, decision and remediation instructions=20 5. SHOULD support grouping of attributes to optimize messages/RTs Kaushik Narayanan: The requirements I-D being presented just seems to cover use cases with raw attributes. It does not capture requirements for where rules are being transferred. Paul: Yes. We need to include those requirements as part of the design process. PT Requirements 1. SHOULD incur low overhead for low bandwidth links Kaushik: The low overhead requirement for PT has a cascading requirement on PA and PB protocol requirements. Paul: Yes. There are PA and PB efficiency requirements also. Kaushik: And data needs to be compact. 2. SHOULD be capable of using a half duplex link 3. MUST NOT interpret the contents of PB messages 4. Capable of protecting the integrity and confidentiality of the PB messages Yaron: Will PT requirements cover everything all the way down to the IP layer? Paul: No, we'll primarily capture the requirements of the transport and not all layers below the PT. Yaron: The Requirements I-D talks about EAP as the transport. Steve: That's an historical artifact. Kapil: The requirement for PT to protect PB messages and the requirement for PT not to interpret PB messages seem to be in conflict. If PT protects PB messages, we can't keep it from interpreting them. And how would you test compliance with those requirements, anyway? Paul: These are requirements on the PT protocol. We wouldn't pick a PT that requires poking around in PB messages. 5. Reliable delivery of PB messages (detect dups, fragmentation) 6. Capable of mutual authentication (possibly leveraging an authentication inside the protected tunnel) 7. Establish a restricted session between NAR and NAA prior to allowing general access 8. Allow for NAR/NAA session to be initiated from either party when both have assigned network addresses Steve discussed next steps: 1) Solicit Design Team Members (through Nov. 16) 2) Start Design Team Weekly Concalls (probably week of Nov. 27) 3) First Requirements I-D Posted Meeting adjourned at 5:17pm _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Dec 08 17:57:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsoeG-0000WZ-K3; Fri, 08 Dec 2006 17:56:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsoeF-0000WU-Hm for nea@ietf.org; Fri, 08 Dec 2006 17:56:55 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsoeE-0005tz-At for nea@ietf.org; Fri, 08 Dec 2006 17:56:55 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 07DEB56452; Fri, 8 Dec 2006 17:56:50 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ki6ac7mdg5KM; Fri, 8 Dec 2006 17:56:42 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 5C1C356460; Fri, 8 Dec 2006 17:56:33 -0500 (EST) Message-ID: <4579EDA2.1050104@cs.utk.edu> Date: Fri, 08 Dec 2006 17:56:34 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Stephen Hanna , Susan Thompson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Sam Hartman , nea@ietf.org Subject: [Nea] use of a design team to develop requirements X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Stephen & Susan, I really have to question the use of a design team to develop requirements for the NEA WG. A lot of the strength of the IETF process has traditionally been from its inclusiveness. Experience suggests that this is most beneficial in two areas - one is determining requirements and design considerations (the more people who have input into these, the more chances there are to spot important considerations that might otherwise have been overlooked) and another is in reviewing documents (the more reviewers, the greater the chance that a flaw in the document is discovered). It's generally a good thing to have a small team to be selected as editors of a document, but IMHO, not so good to make that team responsible for actually determining requirements. If that is really the intent, I think this will tend to impair the ability of the WG to produce a sound set of requirements, particularly when there are a number of dubious assumptions already included in the WG's charter. Particularly given that the list has essentially been silent since the design team was announced, and also given that the design team was formed before much discussion had taken place here, it's hard to escape the impression that the parameters of the solution are being dictated rather than determined by WG consensus, and before the problem is even well understood. I do not believe it is sufficient to have a design team develop requirements in isolation and then to have the WG ratify them. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Dec 08 20:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsrLd-0003qw-3Q; Fri, 08 Dec 2006 20:49:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsrLb-0003qr-EW for nea@ietf.org; Fri, 08 Dec 2006 20:49:51 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsrLY-0002be-31 for nea@ietf.org; Fri, 08 Dec 2006 20:49:51 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Fri, 8 Dec 2006 17:49:47 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.24; Fri, 8 Dec 2006 17:49:46 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Fri, 8 Dec 2006 17:49:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] use of a design team to develop requirements Date: Fri, 8 Dec 2006 17:49:10 -0800 Message-ID: In-Reply-To: <4579EDA2.1050104@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] use of a design team to develop requirements Thread-Index: AccbHDXkpMUblXQXSpKViuMNNc9qTwAFp4Bw From: Khaja Ahmed To: Keith Moore , Stephen Hanna , Susan Thompson X-OriginalArrivalTime: 09 Dec 2006 01:49:46.0221 (UTC) FILETIME=[4DE151D0:01C71B34] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nea@ietf.org, Sam Hartman X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I agree with Keith. It is probably fine to have a 'design team' in the sense of a designated set of people who have committed to contribute to the development of requirements. However I would prefer to see the actual work and related discussion conducted on the list. Khaja -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Friday, December 08, 2006 2:57 PM To: Stephen Hanna; Susan Thompson Cc: Sam Hartman; nea@ietf.org Subject: [Nea] use of a design team to develop requirements Stephen & Susan, I really have to question the use of a design team to develop=20 requirements for the NEA WG. A lot of the strength of the IETF process=20 has traditionally been from its inclusiveness. Experience suggests that this is most beneficial in two areas - one is determining requirements=20 and design considerations (the more people who have input into these,=20 the more chances there are to spot important considerations that might=20 otherwise have been overlooked) and another is in reviewing documents=20 (the more reviewers, the greater the chance that a flaw in the document=20 is discovered). It's generally a good thing to have a small team to be selected as=20 editors of a document, but IMHO, not so good to make that team=20 responsible for actually determining requirements. If that is really=20 the intent, I think this will tend to impair the ability of the WG to=20 produce a sound set of requirements, particularly when there are a=20 number of dubious assumptions already included in the WG's charter. Particularly given that the list has essentially been silent since the=20 design team was announced, and also given that the design team was=20 formed before much discussion had taken place here, it's hard to escape=20 the impression that the parameters of the solution are being dictated=20 rather than determined by WG consensus, and before the problem is even=20 well understood. I do not believe it is sufficient to have a design=20 team develop requirements in isolation and then to have the WG ratify them. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Dec 08 23:50:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsuA1-0001DL-Ms; Fri, 08 Dec 2006 23:50:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gsu9z-0001CV-VZ for nea@ietf.org; Fri, 08 Dec 2006 23:50:03 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gsu9y-0006GX-LL for nea@ietf.org; Fri, 08 Dec 2006 23:50:03 -0500 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 08 Dec 2006 20:49:59 -0800 Received: from orsmsx335.jf.intel.com ([10.22.226.40]) by fmsmga001.fm.intel.com with ESMTP; 08 Dec 2006 20:49:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,516,1157353200"; d="scan'208"; a="175146395:sNHT29677928" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Dec 2006 20:49:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] use of a design team to develop requirements Date: Fri, 8 Dec 2006 20:48:27 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] use of a design team to develop requirements Thread-Index: AccbHDXkpMUblXQXSpKViuMNNc9qTwAFp4BwAAQmAVA= From: "Khosravi, Hormuzd M" To: "Khaja Ahmed" , "Keith Moore" , "Stephen Hanna" , "SusanThompson" X-OriginalArrivalTime: 09 Dec 2006 04:49:59.0531 (UTC) FILETIME=[7B1D7BB0:01C71B4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Sam Hartman , nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I agree with this as well, and I am sure other "design team" members also agree. Infact, we have already had lots of discussions on the mailing lists on the requirements and that's driving a lot of what we are putting in the draft. Also I don't believe the intent of a small design team was to exclude mailing lists discussions & participation. I look towards the chairs for advice on the specifics of this process...my personal thoughts would be sharing weekly design team meeting summary, send out an early rev of the draft for feedback, etc. Regards Hormuzd -----Original Message----- From: Khaja Ahmed [mailto:khaja@windows.microsoft.com]=20 Sent: Friday, December 08, 2006 5:49 PM To: Keith Moore; Stephen Hanna; SusanThompson Cc: nea@ietf.org; Sam Hartman Subject: RE: [Nea] use of a design team to develop requirements I agree with Keith. It is probably fine to have a 'design team' in the sense of a designated set of people who have committed to contribute to the development of requirements. However I would prefer to see the actual work and related discussion conducted on the list. Khaja -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Friday, December 08, 2006 2:57 PM To: Stephen Hanna; Susan Thompson Cc: Sam Hartman; nea@ietf.org Subject: [Nea] use of a design team to develop requirements Stephen & Susan, I really have to question the use of a design team to develop=20 requirements for the NEA WG. A lot of the strength of the IETF process=20 has traditionally been from its inclusiveness. Experience suggests that this is most beneficial in two areas - one is determining requirements=20 and design considerations (the more people who have input into these,=20 the more chances there are to spot important considerations that might=20 otherwise have been overlooked) and another is in reviewing documents=20 (the more reviewers, the greater the chance that a flaw in the document=20 is discovered). It's generally a good thing to have a small team to be selected as=20 editors of a document, but IMHO, not so good to make that team=20 responsible for actually determining requirements. If that is really=20 the intent, I think this will tend to impair the ability of the WG to=20 produce a sound set of requirements, particularly when there are a=20 number of dubious assumptions already included in the WG's charter. Particularly given that the list has essentially been silent since the=20 design team was announced, and also given that the design team was=20 formed before much discussion had taken place here, it's hard to escape=20 the impression that the parameters of the solution are being dictated=20 rather than determined by WG consensus, and before the problem is even=20 well understood. I do not believe it is sufficient to have a design=20 team develop requirements in isolation and then to have the WG ratify them. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sat Dec 09 00:24:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsuhQ-00046r-3p; Sat, 09 Dec 2006 00:24:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GsuhP-00046j-BK for nea@ietf.org; Sat, 09 Dec 2006 00:24:35 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GsuhO-0005Xy-4U for nea@ietf.org; Sat, 09 Dec 2006 00:24:35 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id B9103FD65; Sat, 9 Dec 2006 00:24:29 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlvbdK-zoBKl; Sat, 9 Dec 2006 00:24:25 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id B0BD9FD5D; Sat, 9 Dec 2006 00:24:24 -0500 (EST) Message-ID: <457A488A.9060302@cs.utk.edu> Date: Sat, 09 Dec 2006 00:24:26 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "Khosravi, Hormuzd M" Subject: Re: [Nea] use of a design team to develop requirements References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Sam Hartman , nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > I agree with this as well, and I am sure other "design team" members > also agree. Infact, we have already had lots of discussions on the > mailing lists on the requirements and that's driving a lot of what we > are putting in the draft. Also I don't believe the intent of a small > design team was to exclude mailing lists discussions & participation. > > I look towards the chairs for advice on the specifics of this > process...my personal thoughts would be sharing weekly design team > meeting summary, send out an early rev of the draft for feedback, etc. my belief is that the "design team" should not be drafting any requirements text in advance of list discussion. instead, they should try to write up goals and requirements based on the discussion on the list, with an eye to what kind of language might reach consensus. something else they might try to do is to come up with topics for discussion - e.g. name some categories for requirements that should be discussed, or mention tradeoffs and ask the list what's an appropriate compromise for each. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sat Dec 09 06:38:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt0X7-0003Gz-Qx; Sat, 09 Dec 2006 06:38:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gt0X6-0003Gu-IM for nea@ietf.org; Sat, 09 Dec 2006 06:38:20 -0500 Received: from borg.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gt0X5-0006v4-0s for nea@ietf.org; Sat, 09 Dec 2006 06:38:20 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 09 Dec 2006 03:35:02 -0800 X-IronPort-AV: i="4.09,517,1157353200"; d="scan'208"; a="634076869:sNHT64376322" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] use of a design team to develop requirements Date: Sat, 9 Dec 2006 06:38:14 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] use of a design team to develop requirements Thread-index: AccbHDXkpMUblXQXSpKViuMNNc9qTwAFp4BwABTnHfA= From: "Stephen Hanna" To: "Khaja Ahmed" , "Keith Moore" , "Susan Thompson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: nea@ietf.org, Sam Hartman X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org A better time for this discussion would have been at the NEA WG meeting or during the month since then. I sent email to the NEA list on November 8 explaining that a requirements design team was being formed and an email to the SAAG list on November 9 reiterating this. Several more follow-up emails to the NEA list were sent over the next few weeks. The design team is well under way now. But I suppose it's never too late for an objection. Certainly, the intent of using a design team is not to exclude mailing list discussions and participation. It's to prepare a reasonable starting proposal for discussions. This is not an unusual process in the IETF. Working groups often create a design team to solve a problem or create a first draft of a specification. In fact, many specs are initially drafted by one person and then revised in response to discussions on the mailing list. As long as the initial draft from the design team is regarded as only an initial proposal subject to revision or rejection by the working group, this is a perfectly acceptable process. In fact, RFC 2418 describes this process explicitly and positively in section 6.5. We have asked the design team to deliver the first draft of the requirements document in early January. That's a very short timeline and there are a lot of holidays there. If we abandon the design team process and instead hold an unstructured discussion of requirements on the mailing list during this holiday period, I'm concerned that it will not be a productive discussion. I'm especially concerned that many working group participants will be absent during this period and one or two people will end up dominating the discussion. I have already seen tendencies in this direction in recent NEA WG discussions. I suggest that we allow the design team to finish their work on the first draft of the requirements document and deliver it to us in early January. Then we can have a free-ranging discussion about the document, any assumptions implicit in the document, what should be done instead, etc. We'll have all hands on deck during January and can have a much more productive and inclusive discussion then. Thanks, Steve -----Original Message----- From: Khaja Ahmed [mailto:khaja@windows.microsoft.com]=20 Sent: Friday, December 08, 2006 8:49 PM To: Keith Moore; Stephen Hanna; Susan Thompson Cc: Sam Hartman; nea@ietf.org Subject: RE: [Nea] use of a design team to develop requirements I agree with Keith. It is probably fine to have a 'design team' in the sense of a designated set of people who have committed to contribute to the development of requirements. However I would prefer to see the actual work and related discussion conducted on the list. Khaja -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Friday, December 08, 2006 2:57 PM To: Stephen Hanna; Susan Thompson Cc: Sam Hartman; nea@ietf.org Subject: [Nea] use of a design team to develop requirements Stephen & Susan, I really have to question the use of a design team to develop=20 requirements for the NEA WG. A lot of the strength of the IETF process=20 has traditionally been from its inclusiveness. Experience suggests that this is most beneficial in two areas - one is determining requirements=20 and design considerations (the more people who have input into these,=20 the more chances there are to spot important considerations that might=20 otherwise have been overlooked) and another is in reviewing documents=20 (the more reviewers, the greater the chance that a flaw in the document=20 is discovered). It's generally a good thing to have a small team to be selected as=20 editors of a document, but IMHO, not so good to make that team=20 responsible for actually determining requirements. If that is really=20 the intent, I think this will tend to impair the ability of the WG to=20 produce a sound set of requirements, particularly when there are a=20 number of dubious assumptions already included in the WG's charter. Particularly given that the list has essentially been silent since the=20 design team was announced, and also given that the design team was=20 formed before much discussion had taken place here, it's hard to escape=20 the impression that the parameters of the solution are being dictated=20 rather than determined by WG consensus, and before the problem is even=20 well understood. I do not believe it is sufficient to have a design=20 team develop requirements in isolation and then to have the WG ratify them. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Dec 10 04:49:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtLIU-0007AI-1f; Sun, 10 Dec 2006 04:48:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GtLIS-00079K-5D for nea@ietf.org; Sun, 10 Dec 2006 04:48:36 -0500 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GtLIO-0006mf-Pr for nea@ietf.org; Sun, 10 Dec 2006 04:48:36 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VHk4fsKEIqPI2BpaBZ0wHBhP4YWzCD7Q5bwK9PWnkAz+HH7YPidwrgCx4IvtdiAk; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [66.245.6.28] (helo=gw) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GtLIL-0003Ox-Te; Sun, 10 Dec 2006 04:48:30 -0500 Message-ID: <001a01c71c40$5b1c8970$2101a8c0@home.glassey.com> From: "todd glassey" To: "Khosravi, Hormuzd M" , "Khaja Ahmed" , "Keith Moore" , "Stephen Hanna" , "SusanThompson" References: Subject: Re: [Nea] use of a design team to develop requirements Date: Sun, 10 Dec 2006 01:48:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79e6dca6836f5e4d4fa171015726e56387350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.6.28 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nea@ietf.org, Sam Hartman X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Keith and Khaja - are you speaking for yourselves or your sponsors? Todd Glassey ----- Original Message ----- From: "Khosravi, Hormuzd M" To: "Khaja Ahmed" ; "Keith Moore" ; "Stephen Hanna" ; "SusanThompson" Cc: "Sam Hartman" ; Sent: Friday, December 08, 2006 8:48 PM Subject: RE: [Nea] use of a design team to develop requirements I agree with this as well, and I am sure other "design team" members also agree. Infact, we have already had lots of discussions on the mailing lists on the requirements and that's driving a lot of what we are putting in the draft. Also I don't believe the intent of a small design team was to exclude mailing lists discussions & participation. I look towards the chairs for advice on the specifics of this process...my personal thoughts would be sharing weekly design team meeting summary, send out an early rev of the draft for feedback, etc. Regards Hormuzd -----Original Message----- From: Khaja Ahmed [mailto:khaja@windows.microsoft.com] Sent: Friday, December 08, 2006 5:49 PM To: Keith Moore; Stephen Hanna; SusanThompson Cc: nea@ietf.org; Sam Hartman Subject: RE: [Nea] use of a design team to develop requirements I agree with Keith. It is probably fine to have a 'design team' in the sense of a designated set of people who have committed to contribute to the development of requirements. However I would prefer to see the actual work and related discussion conducted on the list. Khaja -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu] Sent: Friday, December 08, 2006 2:57 PM To: Stephen Hanna; Susan Thompson Cc: Sam Hartman; nea@ietf.org Subject: [Nea] use of a design team to develop requirements Stephen & Susan, I really have to question the use of a design team to develop requirements for the NEA WG. A lot of the strength of the IETF process has traditionally been from its inclusiveness. Experience suggests that this is most beneficial in two areas - one is determining requirements and design considerations (the more people who have input into these, the more chances there are to spot important considerations that might otherwise have been overlooked) and another is in reviewing documents (the more reviewers, the greater the chance that a flaw in the document is discovered). It's generally a good thing to have a small team to be selected as editors of a document, but IMHO, not so good to make that team responsible for actually determining requirements. If that is really the intent, I think this will tend to impair the ability of the WG to produce a sound set of requirements, particularly when there are a number of dubious assumptions already included in the WG's charter. Particularly given that the list has essentially been silent since the design team was announced, and also given that the design team was formed before much discussion had taken place here, it's hard to escape the impression that the parameters of the solution are being dictated rather than determined by WG consensus, and before the problem is even well understood. I do not believe it is sufficient to have a design team develop requirements in isolation and then to have the WG ratify them. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 12 00:37:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu0Jj-0002Z7-0a; Tue, 12 Dec 2006 00:36:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu0Ji-0002Z1-3J for nea@ietf.org; Tue, 12 Dec 2006 00:36:38 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu0Jf-0003t9-NR for nea@ietf.org; Tue, 12 Dec 2006 00:36:38 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 37100564EA for ; Tue, 12 Dec 2006 00:36:30 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VELWjQF4OY0g; Tue, 12 Dec 2006 00:36:24 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 58FBD564E5; Tue, 12 Dec 2006 00:36:20 -0500 (EST) Message-ID: <457E3FD6.5030704@cs.utk.edu> Date: Tue, 12 Dec 2006 00:36:22 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: nea@ietf.org Subject: [Fwd: Re: [Nea] use of a design team to develop requirements] Content-Type: multipart/mixed; boundary="------------050808040006060709040103" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --------------050808040006060709040103 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------050808040006060709040103 Content-Type: message/rfc822; name="Re: [Nea] use of a design team to develop requirements" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: [Nea] use of a design team to develop requirements" Return-Path: X-Original-To: moore@cs.utk.edu Received: from shu.cs.utk.edu (shu.cs.utk.edu [160.36.56.39]) by yomega.cs.utk.edu (Postfix) with ESMTP id B7CE48D056 for ; Tue, 12 Dec 2006 00:30:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 87522564E5 for ; Tue, 12 Dec 2006 00:34:40 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-100 required=5 tests=[BAYES_00=-2.599] Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dTavaqe05X1o; Tue, 12 Dec 2006 00:34:32 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id A3BD4564E4; Tue, 12 Dec 2006 00:34:30 -0500 (EST) Message-ID: <457E3F68.2090905@cs.utk.edu> Date: Tue, 12 Dec 2006 00:34:32 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "Susan Thomson (sethomso)" CC: Khaja Ahmed , Stephen Hanna , Sam Hartman , Russ Housley Subject: Re: [Nea] use of a design team to develop requirements References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit -------- Original Message -------- > Hi Keith > > The purpose of the "design team" is to put a proposal on the table for > discussion. This would be a first draft and in no way can be considered > to reflect WG consensus. Susan, As I've already stated, I don't think this is an appropriate use of a design team. First, requirements should not be drafted before a shared understanding of the problem has been developed within the working group, otherwise the group members are not on the same page. There's been almost no discussion of the problem on the mailing list, and what little discussion has taken place is sufficient to indicate that there's not a shared understanding of the problem yet. Second, having a hand-picked design team draft an initial set of requirements unfairly biases the requirements towards the points-of-view of those individuals. Requirements and design goals need to come from a broad survey, not from the opinions of a few handpicked people. I also take issue with the goal of getting an initial requirements draft out by January, because that's nowhere nearly enough time to get a shared understanding of the problem, much less to develop requirements. I also find it suspicious that the "participants in the NEA Requirements Team" mentioned in draft-khosravi-nea-requirements-01.txt, which was published in July 2006 (before this working group was chartered), include both co-chairs of this working group as well as three out of five members of the design that those co-chairs have handpicked. It is hard to escape the impression that the design team was picked precisely to further the goals of a narrow set of people rather than to reflect the broader interests of the working group, or of the Internet community. Keith --------------050808040006060709040103 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --------------050808040006060709040103-- From nea-bounces@ietf.org Tue Dec 12 09:37:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8l7-0000J6-Hk; Tue, 12 Dec 2006 09:37:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu8bA-0003Ui-J4 for nea@ietf.org; Tue, 12 Dec 2006 09:27:12 -0500 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu8b9-0007wi-AK for nea@ietf.org; Tue, 12 Dec 2006 09:27:12 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id F076DE0050; Tue, 12 Dec 2006 09:27:01 -0500 (EST) From: Sam Hartman To: Keith Moore References: <4579EDA2.1050104@cs.utk.edu> Date: Tue, 12 Dec 2006 09:27:01 -0500 In-Reply-To: <4579EDA2.1050104@cs.utk.edu> (Keith Moore's message of "Fri, 08 Dec 2006 17:56:34 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Tue, 12 Dec 2006 09:37:28 -0500 Cc: nea@ietf.org Subject: [Nea] Re: use of a design team to develop requirements X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org >>>>> "Keith" == Keith Moore writes: Keith> Stephen & Susan, I really have to question the use of a Keith> design team to develop requirements for the NEA WG. A lot Keith> of the strength of the IETF process has traditionally been Keith> from its inclusiveness. Experience suggests that this is Keith> most beneficial in two areas - one is determining Keith> requirements and design considerations (the more people who Keith> have input into these, the more chances there are to spot Keith> important considerations that might otherwise have been Keith> overlooked) and another is in reviewing documents (the more Keith> reviewers, the greater the chance that a flaw in the Keith> document is discovered). Keith, speaking only to the correctness of process: it is absolutely clear to me that a WG can choose to use a design team to solve any problem before them. However, for sponsored design teams, it's also clear to me that decision is subject to WG consensus like all other WG decisinos. Discussing the formation of the team at the meeting and then on the list seems to meet the requirement of confirming WG consensus for that decision. Obviously, ad-hoc design teams formed by participants and not given support by the chair can be formed for any problem without the approval of the WG. That too is a critical part of the IETF process. Again, I'm speaking to process issues, not to whether it is right to form a design team in this case. Also, as you well know, this is Russ's group not mine; my opinion here holds no more weight than your own. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 12 10:40:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9kI-0000vJ-Hs; Tue, 12 Dec 2006 10:40:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu9kH-0000vA-78 for nea@ietf.org; Tue, 12 Dec 2006 10:40:41 -0500 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu9kF-0007co-CI for nea@ietf.org; Tue, 12 Dec 2006 10:40:41 -0500 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 808CB2F26E; Tue, 12 Dec 2006 10:40:38 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8dYQhpYD8qPH; Tue, 12 Dec 2006 10:40:31 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 09C482F26C; Tue, 12 Dec 2006 10:40:17 -0500 (EST) Message-ID: <457ECD5D.8040906@cs.utk.edu> Date: Tue, 12 Dec 2006 10:40:13 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Sam Hartman References: <4579EDA2.1050104@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nea@ietf.org Subject: [Nea] Re: use of a design team to develop requirements X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org -------- Original Message -------- >>>>>> "Keith" == Keith Moore writes: > > Keith> Stephen & Susan, I really have to question the use of a > Keith> design team to develop requirements for the NEA WG. A lot > Keith> of the strength of the IETF process has traditionally been > Keith> from its inclusiveness. Experience suggests that this is > Keith> most beneficial in two areas - one is determining > Keith> requirements and design considerations (the more people who > Keith> have input into these, the more chances there are to spot > Keith> important considerations that might otherwise have been > Keith> overlooked) and another is in reviewing documents (the more > Keith> reviewers, the greater the chance that a flaw in the > Keith> document is discovered). > > Keith, speaking only to the correctness of process: it is absolutely > clear to me that a WG can choose to use a design team to solve any > problem before them. strictly speaking, it may be allowed by our process, though I think of this as an omission or ambiguity in our process documents. I don't think our process was intended to allow handpicked design teams to develop requirements. I also think that is is contrary to good engineering practice and common sense to try to define requirements of a solution before the problem itself is well understood. the chairs and the design team may believe that they understand the problem well, but they haven't bothered to get much input from the larger group before starting to draft requirements. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 12 14:43:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDXG-0002jp-Gm; Tue, 12 Dec 2006 14:43:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuDXF-0002jg-8b for nea@ietf.org; Tue, 12 Dec 2006 14:43:29 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuDXA-0007eo-UA for nea@ietf.org; Tue, 12 Dec 2006 14:43:29 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id C2C1CA70BA; Tue, 12 Dec 2006 11:43:21 -0800 (PST) Message-ID: <457F059C.2010200@deployingradius.com> Date: Tue, 12 Dec 2006 11:40:12 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Keith Moore Subject: Re: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> In-Reply-To: <457ECD5D.8040906@cs.utk.edu> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: nea@ietf.org, Sam Hartman X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Keith Moore wrote: > I also think that is is contrary to good engineering practice and common > sense to try to define requirements of a solution before the problem > itself is well understood. the chairs and the design team may believe > that they understand the problem well, but they haven't bothered to get > much input from the larger group before starting to draft requirements. Then let's discuss the requirements here. Personally, I think that there are many kinds of endpoint assessment that can be done simply by leveraging information in existing protocols. e.g. MAC address filtering in DHCP, to allow only known hosts onto the network. None of those steps to a full-blown NEA are perfect, but NEA won't be perfect, either. I would like to see the requirements stated as a series of stages, from "anyone is allowed on the network with no checks", to "you must submit to invasive probes", with a graduated range of assessments in between. The main problem I see with that approach is the extremes are easy to document, but the grey area in the middle is difficult to quantify. Maybe even before requirements, we should discuss what information exists where, and who is willing to exchange what information. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 12:51:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuYFg-0002Xr-PG; Wed, 13 Dec 2006 12:50:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuYFf-0002Xk-PY for nea@ietf.org; Wed, 13 Dec 2006 12:50:43 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuYFe-0002gF-Dq for nea@ietf.org; Wed, 13 Dec 2006 12:50:43 -0500 Received: by nz-out-0506.google.com with SMTP id z6so132719nzd for ; Wed, 13 Dec 2006 09:50:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eFhZZ65JEjRymKzXziU1JP7ADu02Rx1doH8ieoCUuuVHM760FFbus1SceSW/KvgADdLhMC0uuQA9nKDgIyFQjnFPPMJmvg2UN9xpGaU3YtPBeuMfmTAO/j7qkylaG0DntU0z6nVe2Lc4SauXW5u/VhCV93SAoemWvXxUxoEQvzs= Received: by 10.65.192.16 with SMTP id u16mr1838456qbp.1166032241079; Wed, 13 Dec 2006 09:50:41 -0800 (PST) Received: by 10.65.158.12 with HTTP; Wed, 13 Dec 2006 09:50:41 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 12:50:41 -0500 From: "Mike Fratto" To: nea@ietf.org Subject: Fwd: [Nea] Re: use of a design team to develop requirements In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > I would like to see the requirements stated as a series of stages, > from "anyone is allowed on the network with no checks", to "you must > submit to invasive probes", with a graduated range of assessments in > between. Alan, this needs to be generalized to something like "products must have configurable actions based on posture assessment" but this is a policy or action statement that will be defined by oranganizations and is beyond the scope of the working group. It's important and perhaps an informational RFC on best practices would be a good spot for those types of discussions. At this point, it looks like the requirements are focusing on features that should be in PA and PB. For example, I think it is critical: 1) that a set of basic attributes such as MAC, IP, and NEA client time, be defined that MUST be exchanged between a NEA client and NEA server 2) that the NEA attributes sent to the NEA server from the NEA client be secured in such a way that only the NEA server can open and view them 3) that prior to attribute exchange there is a mechanism in place where the NEA server requests attributes and the NEA client makes a choice according to it's local policy whether to send those attributes or not. Perhaps a negotiation MUST take place even if that means the server policy dictates all attributes must be returned. (default NAK). I am thinking of something similar to PPP. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 13:28:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuYq1-0002x9-H7; Wed, 13 Dec 2006 13:28:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuYpz-0002uq-Kz for nea@ietf.org; Wed, 13 Dec 2006 13:28:15 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuYpx-0000FA-30 for nea@ietf.org; Wed, 13 Dec 2006 13:28:15 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id C0908A7112; Wed, 13 Dec 2006 10:28:05 -0800 (PST) Message-ID: <45804574.9040400@deployingradius.com> Date: Wed, 13 Dec 2006 10:24:52 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Mike Fratto wrote: > Alan, this needs to be generalized to something like "products must > have configurable actions based on posture assessment" That statement is already assuming a host of requirements and functionality. My intent was to describe the *administrators* requirements for controlling network access, independent of the capabilities of the end hosts. Once those requirements are quantified, we can then move on to describing the requirements that the end hosts have to meet in order to satisfy the larger objectives. According to the charter, this is part of what the requirements document is supposed to cover. Since there were concerns raised about the openness of the process, I would like to see a public discussion here. If there is no public discussion about the requirements, then the WG members are saying they have no opinion about the requirements, and that we should just rubber-stamp whatever document is produced by the requirements team. > For example, I think it is critical: > > 1) that a set of basic attributes such as MAC, IP, and NEA client > time, be defined that MUST be exchanged between a NEA client and NEA > server To what end? I'm not being facetious here. The charter indicates that the requirements document should include a problem statement. We should discuss that before talking about attributes and solutions. My $0.02 for a problem statement is that administrators want to know: 1) who is on their network (users/machines) 2) that those users/machines engage in behavior that is mutually agreed to by the users and network administrators. The invasive "scan your machine" system that Keith is rightly worried about is a poor proxy for statement (2). i.e. It's hard to put content scanners everywhere in the network, to prevent bad behavior, so the next best thing is to ensure that all the machines have patchlevel X, because we know it's not vulnerable to an attack which as a side effect produces bad behavior. To put it another way, it doesn't matter much if a machine is vulnerable to an attack, so long as that attack is never executed. Many of the claimed NEA benefits about controlling network access can be achieved by leveraging information that's already in the network, but which isn't being looked at or used. Many more of the NEA benefits about protecting the network can be achieved by running IDS machines, or by traffic filtering on the switch/router. And other NEA benefits about controlling the remote machine can be obtained by running the vulnerable OS's in a VMware image, on a host OS that is much less vulnerable. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 14:40:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuZxR-0001Sl-3s; Wed, 13 Dec 2006 14:40:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuZxQ-0001SU-9Z for nea@ietf.org; Wed, 13 Dec 2006 14:40:00 -0500 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuZxP-0001nG-16 for nea@ietf.org; Wed, 13 Dec 2006 14:40:00 -0500 Received: by nz-out-0506.google.com with SMTP id z6so152789nzd for ; Wed, 13 Dec 2006 11:39:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BzaKye2JNk7wb9Fp9aEFpiRAvpYSw45Yee1RBiniCyUc9bOkXLNqPRrwyEE8uLpAnttb2ZADTbXBjQT6IC6mDu538eBnaWilY5phEQ1DxtkiXXBtmWL1gEYBGlq8PD+tQQQrdeR9GvfJSSUYXAKrV4bE0XEqp3euVIZ2N5bGAZo= Received: by 10.64.243.15 with SMTP id q15mr2023866qbh.1166038798409; Wed, 13 Dec 2006 11:39:58 -0800 (PST) Received: by 10.65.158.12 with HTTP; Wed, 13 Dec 2006 11:39:58 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 14:39:58 -0500 From: "Mike Fratto" To: "Alan DeKok" Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements In-Reply-To: <45804574.9040400@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > That statement is already assuming a host of requirements and > functionality. My intent was to describe the *administrators* > requirements for controlling network access, independent of the > capabilities of the end hosts. Ok, I am not going to act as charter police, but what you are describing is a matter local policy and a matter of deployed infrastructure regarding both assessment and enforcement. Maybe I am wrong about that, but I don't think so. ha-ha :) > My $0.02 for a problem statement is that administrators want to know: > > 1) who is on their network (users/machines) > 2) that those users/machines engage in behavior that is mutually agreed > to by the users and network administrators. I think your problem statement is too specific and really is kind of obvious. Organizations are assessing, piloting, and deploying network access control solutions today and in the next year or so. That is happening regardless of what happens in this, or any, group. But I think the problem statement that NAC address (from talking to those very same organizations) more generally comes down to the following: Network owners want to control access to network resources based on a one or more factors such as (this is NOT an exhaustive list), MAC address, IP address, location, time of day, host configuration, assessment of installed applicaitons, assessment of running applications, determination of whether the host is known or unknown, and operating system patch levels and network owners want interoperable products that will grant host assessment, remeidation, and enforcement. In short, network owners want the tools that will allow them to enforce a policy they deem appropriate for thier network. That is the problem NAC attempts to solve (for better or worse, that is also debateable) Making the resonable asusmption that NAC is being deployed, the problem with the NAC market today is that there are three competing frameworks, Cisco Network Admission Contron, Microsoft Network Access Protection, and the Trusted Computing Group Trusted Network Connect. Cisco and Microsoft have announced interoperabilty plans, but neither interperate with TNC. That means there is a very real possibility that the market will continue to be fractured and that means interoperation will be impossible and that hurts organizations deploying NAC. If your chosen products don't conform with a specific framework, then you're SoL. For example, if a host attempts to access the network, but their host software can't be assessed because it does not interoperate with the assessment tool, that is a problem. That is a very differnet problem than a host denying an assessment transmitted through an agreed upon protocol. So the problem really comes down to getting the different frameworks to interoperate and also to allow other products to interoperate regarding host assessment. That leads me back to my short bullet list which addresses what the protocols should support. mike _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 15:45:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guayl-0006DN-9i; Wed, 13 Dec 2006 15:45:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guayk-0006C3-9h for nea@ietf.org; Wed, 13 Dec 2006 15:45:26 -0500 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guayj-0001zS-36 for nea@ietf.org; Wed, 13 Dec 2006 15:45:26 -0500 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 9FB722F292; Wed, 13 Dec 2006 15:45:25 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt+s3bq7vCX7; Wed, 13 Dec 2006 15:45:22 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ka.cs.utk.edu (Postfix) with ESMTP id E90FE2F291; Wed, 13 Dec 2006 15:45:17 -0500 (EST) Date: Wed, 13 Dec 2006 15:46:43 -0500 From: Keith Moore To: "Mike Fratto" Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements Message-Id: <20061213154643.bba35cbe.moore@cs.utk.edu> In-Reply-To: References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > > I would like to see the requirements stated as a series of stages, > > from "anyone is allowed on the network with no checks", to "you must > > submit to invasive probes", with a graduated range of assessments in > > between. > > Alan, this needs to be generalized to something like "products must > have configurable actions based on posture assessment" but this is a > policy or action statement that will be defined by oranganizations and > is beyond the scope of the working group. I don't know that I agree with the "series of stages" argument, but the topic is certainly NOT beyond the scope of the WG - because NEA has privacy implications for hosts and such implications could affect the ability of NEA to meet IETF criteria for Proposed Standard status. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 15:50:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gub3q-0000SQ-Cn; Wed, 13 Dec 2006 15:50:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gub3o-0000Rm-Bh for nea@ietf.org; Wed, 13 Dec 2006 15:50:40 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gub3n-0002ni-2N for nea@ietf.org; Wed, 13 Dec 2006 15:50:40 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 08318FD14; Wed, 13 Dec 2006 15:50:33 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmgsqYC4Lruk; Wed, 13 Dec 2006 15:50:29 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by bes.cs.utk.edu (Postfix) with ESMTP id B629BFD0D; Wed, 13 Dec 2006 15:50:24 -0500 (EST) Date: Wed, 13 Dec 2006 15:51:59 -0500 From: Keith Moore To: "Mike Fratto" Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements Message-Id: <20061213155159.b457af48.moore@cs.utk.edu> In-Reply-To: References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > > That statement is already assuming a host of requirements and > > functionality. My intent was to describe the *administrators* > > requirements for controlling network access, independent of the > > capabilities of the end hosts. > > Ok, I am not going to act as charter police, but what you are > describing is a matter local policy and a matter of deployed > infrastructure regarding both assessment and enforcement. Maybe I am > wrong about that, but I don't think so. ha-ha :) Why in the world should IETF standardize a protocol that enables networks to impose whatever policies they wish on hosts, given that we already understand how this could be harmful to the Internet and counter to IETF's organizational goals? > I think your problem statement is too specific and really is kind of > obvious. Organizations are assessing, piloting, and deploying network > access control solutions today and in the next year or so. Perhaps, but that doesn't justify IETF's endorsement of such practices. > Network owners want to control access to network resources based on a > one or more factors such as (this is NOT an exhaustive list), MAC > address, IP address, location, time of day, host configuration, > assessment of installed applicaitons, assessment of running > applications, determination of whether the host is known or unknown, > and operating system patch levels and network owners want > interoperable products that will grant host assessment, remeidation, > and enforcement. In short, network owners want the tools that will > allow them to enforce a policy they deem appropriate for thier > network. That is the problem NAC attempts to solve (for better or > worse, that is also debateable) > > Making the resonable asusmption that NAC is being deployed, the > problem with the NAC market today is that there are three competing > frameworks, Cisco Network Admission Contron, Microsoft Network Access > Protection, and the Trusted Computing Group Trusted Network Connect. > Cisco and Microsoft have announced interoperabilty plans, but neither > interperate with TNC. That means there is a very real possibility that > the market will continue to be fractured and that means interoperation > will be impossible and that hurts organizations deploying NAC. If > your chosen products don't conform with a specific framework, then > you're SoL. For example, if a host attempts to access the network, but > their host software can't be assessed because it does not interoperate > with the assessment tool, that is a problem. That is a very differnet > problem than a host denying an assessment transmitted through an > agreed upon protocol. > > So the problem really comes down to getting the different frameworks > to interoperate and also to allow other products to interoperate > regarding host assessment. That leads me back to my short bullet list > which addresses what the protocols should support. Interoperability is not always a good thing. Making it easier for networks to impose draconinan and intrustive policies on hosts that they do not own is not consistent with IETF goals. NEA either needs to be fixed so that it balances risk between host, user, and network, or it needs to be taken out of IETF. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 17:37:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gucik-00043v-C9; Wed, 13 Dec 2006 17:37:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gucii-00043f-HJ for nea@ietf.org; Wed, 13 Dec 2006 17:37:00 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gucid-00053B-VX for nea@ietf.org; Wed, 13 Dec 2006 17:37:00 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 1C720A7112; Wed, 13 Dec 2006 14:36:52 -0800 (PST) Message-ID: <45807FC4.7090706@deployingradius.com> Date: Wed, 13 Dec 2006 14:33:40 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Mike Fratto wrote: > Ok, I am not going to act as charter police, but what you are > describing is a matter local policy and a matter of deployed > infrastructure regarding both assessment and enforcement. If all requirements are a matter of local policy, then this WG will never develop a standard. > I think your problem statement is too specific and really is kind of > obvious. It still needs saying. Much of the NEA architecture and requirements are obvious to many, but perhaps not to all. That's why we have working groups and public discussions: to publicly ensure we have consensus. > Network owners want to control access to network resources based on a > one or more factors such as ... Many versions of this have been deployed already, some for decades. I believe we need to spend *some* time enumerating what's deployed and what works, before we go design complex systems systems. If we don't, then there's a good chance we will re-invent what already exists. > Making the resonable asusmption that NAC is being deployed, the > problem with the NAC market today is that there are three competing > frameworks, Cisco Network Admission Contron, Microsoft Network Access > Protection, and the Trusted Computing Group Trusted Network Connect. How does the TNC overlap with NEA? The chair of NEA is also the chair of TNC, but I haven't seen any statement about that topic. > Cisco and Microsoft have announced interoperabilty plans, but neither > interperate with TNC. That means there is a very real possibility that > the market will continue to be fractured and that means interoperation > will be impossible and that hurts organizations deploying NAC. Interoperation of... what, exactly? Again, discussion of the requirements and architecture is on topic for this list. You're skipping over that entirely, and assuming certain technologies. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 17:42:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guco0-0006xa-L0; Wed, 13 Dec 2006 17:42:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gucny-0006wV-W3 for nea@ietf.org; Wed, 13 Dec 2006 17:42:26 -0500 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gucnv-0005y3-KA for nea@ietf.org; Wed, 13 Dec 2006 17:42:26 -0500 Received: by nz-out-0506.google.com with SMTP id z6so181466nzd for ; Wed, 13 Dec 2006 14:42:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IPJ3OFRF3LEGaKzvrp6bDgoMNSN/P8432gfj7MlEDFYMw3o2IM8iuW96KfMwCDWty5kvw7Ma4l5EIAWUab+Oken2MUrwlvS0cu8g3yiTKnG7KtSu5pQW3n+1kloDhH4fEtxWA3p+CvM+Df4UyY6hXqHOBiNfhl4Qwv9cEoCB5JA= Received: by 10.65.241.20 with SMTP id t20mr211295qbr.1166049740609; Wed, 13 Dec 2006 14:42:20 -0800 (PST) Received: by 10.65.158.12 with HTTP; Wed, 13 Dec 2006 14:42:20 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 17:42:20 -0500 From: "Mike Fratto" To: "Keith Moore" Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements In-Reply-To: <20061213155159.b457af48.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > Why in the world should IETF standardize a protocol that enables > networks to impose whatever policies they wish on hosts, given that we > already understand how this could be harmful to the Internet and > counter to IETF's organizational goals? I think I can safely say that the purpose of NAC is NOT to impose anything on a host. The purpose of NAC is to allow a network owner to control access to it's resources, which is well within the network owner's right. Nothing more and nothing less. If a host is not upto snuff and the network owner requires certain actions to take place, the host can *choose* not to participate in the network. There is no forcing anything. There is no other social, racial, national, or political agenda. And no, I don't agree with your claim that NAC is harmful to anyone I can't speak for the IETF at large, but off the top of my noggin here are some other examples of potentially draconian standards, 1) RADIUS is an IETF standard that past muster and is used to control user access. RADIUS imposes the rule that if you can't authenticate, you don't get access. If a user can't authenticate to a RADIUS server for any reason, including not supporting any required authentication mechanisms, then they are denied access. Heck, if you do authenticate and are part of a group, the network can segment you. 2) PKIX is a whole suite of standards. It too can be used to grant or deny access to a number of resource via the presence or absense of attributes or heck, knowledge, or lack of knowlege, of the signing certificate. 3) PPP. Is that also the tool of oppression? Ya know, if a host doesn't accept an offered IP address or other configuration option, they don't attach the network. To think a network owner might want to enforce that! 4) IKE V1 maybe the worst offender of all. If the peers don't find agreement on proposals in the first round of offers, communications stops. Period. There is no negotiation. By your reasoning, none of them should have been in the IETF either. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 18:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GudCD-00037g-F9; Wed, 13 Dec 2006 18:07:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GudCC-00037Z-Fh for nea@ietf.org; Wed, 13 Dec 2006 18:07:28 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GudCB-0000sm-19 for nea@ietf.org; Wed, 13 Dec 2006 18:07:28 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id A6C7EFDBB; Wed, 13 Dec 2006 18:07:20 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LT3R6q5XBMj4; Wed, 13 Dec 2006 18:07:15 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id DD9A7FDBA; Wed, 13 Dec 2006 18:07:14 -0500 (EST) Message-ID: <458087A7.3010907@cs.utk.edu> Date: Wed, 13 Dec 2006 18:07:19 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Alan DeKok Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <45807FC4.7090706@deployingradius.com> In-Reply-To: <45807FC4.7090706@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org >> I think your problem statement is too specific and really is kind of >> obvious. > > It still needs saying. Much of the NEA architecture and requirements > are obvious to many, but perhaps not to all. ...and some of what is "obvious to many" may actually be wrong or misdirected. There's a big difference between developing a product and developing an Internet standard. One important difference is that Internet standards have to function at Internet scale - i.e. what would happen if everyone on the Internet used this however they wanted? That's why a handpicked panel of "experts" isn't fit to develop requirements in isolation - there are no "experts" at doing this on an Internet scale. It needs to be rethought from first principles. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 18:14:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GudIt-0007uC-ML; Wed, 13 Dec 2006 18:14:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GudIs-0007u4-GG for nea@ietf.org; Wed, 13 Dec 2006 18:14:22 -0500 Received: from nz-out-0506.google.com ([64.233.162.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GudIj-00029z-WD for nea@ietf.org; Wed, 13 Dec 2006 18:14:22 -0500 Received: by nz-out-0506.google.com with SMTP id z6so185792nzd for ; Wed, 13 Dec 2006 15:14:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J0tjll/4iW8lUr5ypRdbINYfQLYDqBqCXCW1o3vHj/mWCYKrDNBOTOZMbhAkqvcDkRnxdQC0qFlJQCYvoqoxRvxGOmtV0DYdngU1+WqlLftPssw8vXanDGs4AIsAzAmZ1Vejlpv1UZhWqKoSBCraSNMjP8korq21S8gd6xwt040= Received: by 10.65.20.3 with SMTP id x3mr326253qbi.1166051653610; Wed, 13 Dec 2006 15:14:13 -0800 (PST) Received: by 10.65.158.12 with HTTP; Wed, 13 Dec 2006 15:14:13 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 18:14:13 -0500 From: "Mike Fratto" To: "Alan DeKok" Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements In-Reply-To: <45807FC4.7090706@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <45807FC4.7090706@deployingradius.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org On 12/13/06, Alan DeKok wrote: > Mike Fratto wrote: > > > Ok, I am not going to act as charter police, but what you are > > describing is a matter local policy and a matter of deployed > > infrastructure regarding both assessment and enforcement. > > If all requirements are a matter of local policy, then this WG will > never develop a standard. Nah, local policies are the "WHY". Protocols are the "HOW." It is the how that matters, IMHO, to working groups. > How does the TNC overlap with NEA? The chair of NEA is also the chair > of TNC, but I haven't seen any statement about that topic. To see how the the *functions* of PA, PB, and PT, as defined in the charter are also defined by these other frameworks are related to the work proposed by the NEA, read: http://www.microsoft.com/technet/network/nap/default.mspx http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.html https://www.trustedcomputinggroup.org/groups/network/ If you can't see how the functional aspects of PA, PB, and PT are related to TNC, CNAC and NAP, let me know and I will lay it out for you. > Interoperation of... what, exactly? Again, discussion of the > requirements and architecture is on topic for this list. You're > skipping over that entirely, and assuming certain technologies. No, I am not. Stop being argumentative. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 18:22:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GudR7-0002aZ-S9; Wed, 13 Dec 2006 18:22:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GudR7-0002aQ-Co for nea@ietf.org; Wed, 13 Dec 2006 18:22:53 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GudR6-0003MI-3l for nea@ietf.org; Wed, 13 Dec 2006 18:22:53 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 130B8FD89; Wed, 13 Dec 2006 18:22:46 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RU0smbqWspAe; Wed, 13 Dec 2006 18:22:38 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id D60F3FD17; Wed, 13 Dec 2006 18:22:37 -0500 (EST) Message-ID: <45808B42.8000802@cs.utk.edu> Date: Wed, 13 Dec 2006 18:22:42 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > I think I can safely say that the purpose of NAC is NOT to impose > anything on a host. It's not the explicit purpose, but it is certainly a consequence of NEA if it is successful. If you know something is going to do harm, and you do it anyway, you're still culpable for the harm even if doing harm wasn't your explicit purpose. > The purpose of NAC is to allow a network owner to control access to > it's resources, which is well within the network owner's right. > Nothing more and nothing less. Well, let's look at an analogy. Let's say that you work for me, and I want to establish whether you're trustworthy. So I require you to consent to have your house searched, at any time, for evidence of anything that you might have or do that would cause me to question my trust in you. Would that be well within my rights as an employer? And if it's not okay for me to search your house, why is it okay for me to search your laptop? The real question is something like this - how invasive a search is reasonable? > If a host is not upto snuff and the network owner requires certain > actions to take place, the host can *choose* not to participate in > the network. There is no forcing anything. There is no other social, > racial, national, or political agenda. And no, I don't agree with > your claim that NAC is harmful to anyone I strongly disagree. Saying that a host can choose whether to use a particular network is like saying that a person can choose whether or not to breathe the local air, drink the local water, buy electricity from the local power company. In many cases you have to use a particular network in order to function. So the choice is to a large degree already taken away from the user. When the user doesn't have choice other mechanisms are needed to protect the user's privacy. > > I can't speak for the IETF at large, but off the top of my noggin > here are some other examples of potentially draconian standards, > (RADIUS, PKIX, PPP, IKE) None of these requires arbitrary information from a host - only a small amount of information that specifically exists for the purpose of authentication. And if you can reduce NEA to a protocol that just gives a host a way to say to a network "XYZ virus scanner certifies that this host is good up to version X.Y of its virus tests" then I wouldn't have a problem with it. The problems come from the potential that NEA can be used by a network to ask arbitrary questions of a host. Standardizing spyware is not in the best interest of the Internet community. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 18:25:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GudTb-0003wz-0n; Wed, 13 Dec 2006 18:25:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GudTZ-0003wZ-29 for nea@ietf.org; Wed, 13 Dec 2006 18:25:25 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GudTX-0003kh-Pz for nea@ietf.org; Wed, 13 Dec 2006 18:25:25 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id CB1ECFDBA; Wed, 13 Dec 2006 18:25:17 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8clUhCuK8sRa; Wed, 13 Dec 2006 18:25:11 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id D98DBFDA7; Wed, 13 Dec 2006 18:25:10 -0500 (EST) Message-ID: <45808BDB.4050108@cs.utk.edu> Date: Wed, 13 Dec 2006 18:25:15 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <45807FC4.7090706@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org -------- Original Message -------- > On 12/13/06, Alan DeKok wrote: >> Mike Fratto wrote: >> >> > Ok, I am not going to act as charter police, but what you are >> > describing is a matter local policy and a matter of deployed >> > infrastructure regarding both assessment and enforcement. >> >> If all requirements are a matter of local policy, then this WG will >> never develop a standard. > > Nah, local policies are the "WHY". Protocols are the "HOW." It is the > how that matters, IMHO, to working groups. WGs are certainly concerned with how, but they're also concerned with security implications of their protocols. It's irresponsible to design something that can have harmful consequences without considering those consequences and how to reduce their harmful effects. >> How does the TNC overlap with NEA? The chair of NEA is also the chair >> of TNC, but I haven't seen any statement about that topic. > > To see how the the *functions* of PA, PB, and PT, as defined in the > charter are also defined by these other frameworks are related to the > work proposed by the NEA, read: > > http://www.microsoft.com/technet/network/nap/default.mspx > http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.html > https://www.trustedcomputinggroup.org/groups/network/ Seems like way too much prior work is being assumed to be relevant by certain members of this group. Protocols that weren't designed to work at Internet scale tend to be hard to adapt to Internet scale. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:00:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gue1c-0006G2-Hd; Wed, 13 Dec 2006 19:00:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gue1b-0006EN-Gk for nea@ietf.org; Wed, 13 Dec 2006 19:00:35 -0500 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gue1J-0001jw-Gv for nea@ietf.org; Wed, 13 Dec 2006 19:00:35 -0500 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 13 Dec 2006 16:00:16 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.24; Wed, 13 Dec 2006 16:00:16 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Wed, 13 Dec 2006 16:00:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Fwd: [Nea] Re: use of a design team to develop requirements Date: Wed, 13 Dec 2006 15:59:52 -0800 Message-ID: In-Reply-To: <45808BDB.4050108@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: [Nea] Re: use of a design team to develop requirements Thread-Index: AccfDgCZ+CVbB2yZTQqzhPkDERul7AABCaZA References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu><457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <45807FC4.7090706@deployingradius.com> <45808BDB.4050108@cs.utk.edu> From: Khaja Ahmed To: Keith Moore , Mike Fratto X-OriginalArrivalTime: 14 Dec 2006 00:00:15.0269 (UTC) FILETIME=[D55A5D50:01C71F12] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Wednesday, December 13, 2006 3:25 PM To: Mike Fratto Cc: nea@ietf.org Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements -------- Original Message -------- > On 12/13/06, Alan DeKok wrote: >> Mike Fratto wrote: >> >> > Ok, I am not going to act as charter police, but what you are >> > describing is a matter local policy and a matter of deployed >> > infrastructure regarding both assessment and enforcement. >> >> If all requirements are a matter of local policy, then this WG will >> never develop a standard. >=20 > Nah, local policies are the "WHY". Protocols are the "HOW." It is the > how that matters, IMHO, to working groups. WGs are certainly concerned with how, but they're also concerned with=20 security implications of their protocols. It's irresponsible to design=20 something that can have harmful consequences without considering those=20 consequences and how to reduce their harmful effects. >> How does the TNC overlap with NEA? The chair of NEA is also the chair >> of TNC, but I haven't seen any statement about that topic. >=20 > To see how the the *functions* of PA, PB, and PT, as defined in the > charter are also defined by these other frameworks are related to the > work proposed by the NEA, read: >=20 > http://www.microsoft.com/technet/network/nap/default.mspx > http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.htm l > https://www.trustedcomputinggroup.org/groups/network/ Seems like way too much prior work is being assumed to be relevant by=20 certain members of this group. Protocols that weren't designed to work=20 at Internet scale tend to be hard to adapt to Internet scale. [Khaja] it is not the goals of this WG to produce and protocol that scales to the internet. This is meant to be an enterprise only solution. When I raised this question previously the chairs ruled, and the ADs have concurred, that internet wide behavior (implying ISP participation) is out of scope. Enterprise behavior is the only thing we can consider. =20 [Khaja] Question to chairs: Given that we cannot discuss requirements that pertain to internet wide usage, can we still discuss potential impact of such a protocol if it were to be used in place it is not designed for? ...i.e. the internet. =20 Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:11:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueCT-0003GF-C7; Wed, 13 Dec 2006 19:11:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueCR-0003G5-V9 for nea@ietf.org; Wed, 13 Dec 2006 19:11:47 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GueCQ-0003qU-KL for nea@ietf.org; Wed, 13 Dec 2006 19:11:47 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id C7391A7112; Wed, 13 Dec 2006 16:11:42 -0800 (PST) Message-ID: <45809601.80105@deployingradius.com> Date: Wed, 13 Dec 2006 16:08:33 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Keith Moore Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <45808B42.8000802@cs.utk.edu> In-Reply-To: <45808B42.8000802@cs.utk.edu> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Keith Moore wrote: > Well, let's look at an analogy. Let's say that you work for me, and I > want to establish whether you're trustworthy. So I require you to > consent to have your house searched, at any time, for evidence of > anything that you might have or do that would cause me to question my > trust in you. Would that be well within my rights as an employer? And > if it's not okay for me to search your house, why is it okay for me to > search your laptop? As noted earlier on this list, both kinds of searches may be illegal in certain jurisdictions. Complying with all legal requirements may, in fact be impossible for NEA. >... And if you can reduce NEA to a protocol that just gives > a host a way to say to a network "XYZ virus scanner certifies that this > host is good up to version X.Y of its virus tests" then I wouldn't have > a problem with it. And that's probably not too hard to do, or to retrofit on existing protocols. On the other hand, allowing open-ended queries means that the queries will probably be turing complete. That leaves a wonderful attack vector: Visit a cafe, and have them run arbitrary code on your machine. If the turing complete queries are NOT what is intended, it would be nice to know that, and to have clear statements about what capabilities the queries have. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:15:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueFs-00057S-53; Wed, 13 Dec 2006 19:15:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueFq-00054m-Ap for nea@ietf.org; Wed, 13 Dec 2006 19:15:18 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GueFp-0004SR-3W for nea@ietf.org; Wed, 13 Dec 2006 19:15:18 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 7DDA2FD8A; Wed, 13 Dec 2006 19:15:10 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK-hEWsCrEwT; Wed, 13 Dec 2006 19:15:02 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id B05DCFCDF; Wed, 13 Dec 2006 19:15:01 -0500 (EST) Message-ID: <45809788.1060109@cs.utk.edu> Date: Wed, 13 Dec 2006 19:15:04 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Khaja Ahmed Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu><457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <45807FC4.7090706@deployingradius.com> <45808BDB.4050108@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > [Khaja] it is not the goals of this WG to produce and protocol that > scales to the internet. This is meant to be an enterprise only solution. > When I raised this question previously the chairs ruled, and the ADs > have concurred, that internet wide behavior (implying ISP participation) > is out of scope. Enterprise behavior is the only thing we can consider. Maybe the ADs disagree, but I don't think this flies, for several reasons: One is that IETF has a long history of requiring that its protocols work at Internet scale, even if they are only intended for use within an enterprise network. For instance, we require that protocols have robust authentication even if they're generally expected to be used only behind firewalls. Another is that even if a protocol is only intended to be used on an enterprise network, it will necessarily be installed on large numbers of hosts that are occasionally plugged into other networks, and the security implications of this need to be examined. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:17:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueHY-0006IQ-FJ; Wed, 13 Dec 2006 19:17:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueHX-0006IL-Nz for nea@ietf.org; Wed, 13 Dec 2006 19:17:03 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GueHW-0004iU-D2 for nea@ietf.org; Wed, 13 Dec 2006 19:17:03 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 75E40A7112; Wed, 13 Dec 2006 16:16:58 -0800 (PST) Message-ID: <4580973D.6010106@deployingradius.com> Date: Wed, 13 Dec 2006 16:13:49 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <45807FC4.7090706@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Mike Fratto wrote: > To see how the the *functions* of PA, PB, and PT, as defined in the > charter are also defined by these other frameworks are related to the > work proposed by the NEA, read: > > http://www.microsoft.com/technet/network/nap/default.mspx > http://www.cisco.com/en/US/netsol/ns466/networking_solutions_package.html > https://www.trustedcomputinggroup.org/groups/network/ As I said, you're assuming certain problems, requirements, and architectures. > If you can't see how the functional aspects of PA, PB, and PT are > related to TNC, CNAC and NAP, let me know and I will lay it out for > you. I can see it. I just can't see how you can say you're not assuming certain technologies, and then in the same message, refer to pre-existing technologies as normitive references for NEA terminology and operation. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:18:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueJD-0006cD-Ds; Wed, 13 Dec 2006 19:18:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueJC-0006c8-7G for nea@ietf.org; Wed, 13 Dec 2006 19:18:46 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GueJA-0004we-Va for nea@ietf.org; Wed, 13 Dec 2006 19:18:46 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id D1DB1FDAD; Wed, 13 Dec 2006 19:18:38 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWscGWMrAzhL; Wed, 13 Dec 2006 19:18:31 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 62575FD17; Wed, 13 Dec 2006 19:18:30 -0500 (EST) Message-ID: <4580985A.1000002@cs.utk.edu> Date: Wed, 13 Dec 2006 19:18:34 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Alan DeKok Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <45808B42.8000802@cs.utk.edu> <45809601.80105@deployingradius.com> In-Reply-To: <45809601.80105@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org >> Well, let's look at an analogy. Let's say that you work for me, and I >> want to establish whether you're trustworthy. So I require you to >> consent to have your house searched, at any time, for evidence of >> anything that you might have or do that would cause me to question my >> trust in you. Would that be well within my rights as an employer? And >> if it's not okay for me to search your house, why is it okay for me to >> search your laptop? > > As noted earlier on this list, both kinds of searches may be illegal > in certain jurisdictions. whether the search is illegal is irrelevant to this discussion. if you put a lock on your house, and it's easily defeated, the fact that it's illegal for a spy to defeat the lock and enter your house doesn't mean that the lock was doing its job. >> ... And if you can reduce NEA to a protocol that just gives >> a host a way to say to a network "XYZ virus scanner certifies that this >> host is good up to version X.Y of its virus tests" then I wouldn't have >> a problem with it. > > And that's probably not too hard to do, or to retrofit on existing > protocols. On the other hand, allowing open-ended queries means that > the queries will probably be turing complete. you don't need Turing completeness to be extremely invasive. for example, a way to ask "tell me what the value of octet X at offset Y in file Z" is sufficient to download the entire file system. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:19:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueKA-0006nx-Vx; Wed, 13 Dec 2006 19:19:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueKA-0006nk-4r for nea@ietf.org; Wed, 13 Dec 2006 19:19:46 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GueK8-00054a-Qb for nea@ietf.org; Wed, 13 Dec 2006 19:19:46 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 13 Dec 2006 16:19:44 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.24; Wed, 13 Dec 2006 16:19:38 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Wed, 13 Dec 2006 16:19:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Fwd: [Nea] Re: use of a design team to develop requirements Date: Wed, 13 Dec 2006 16:19:04 -0800 Message-ID: In-Reply-To: <45809788.1060109@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: [Nea] Re: use of a design team to develop requirements Thread-Index: AccfFPSINZE2Ds7bS6mnKjRjYU+adwAADG3A References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu><457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <45807FC4.7090706@deployingradius.com><45808BDB.4050108@cs.utk.edu> <45809788.1060109@cs.utk.edu> From: Khaja Ahmed To: Keith Moore X-OriginalArrivalTime: 14 Dec 2006 00:19:37.0582 (UTC) FILETIME=[8A2540E0:01C71F15] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I appealed to the chairs and the AD. Their position was that the charter should not be changed and it is what it is. So, whether it flies or not, this is what we are stuck with for now. If you have some way of changing that, I would love to see internet wide back in scope. Khaja -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Wednesday, December 13, 2006 4:15 PM To: Khaja Ahmed Cc: nea@ietf.org Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements > [Khaja] it is not the goals of this WG to produce and protocol that > scales to the internet. This is meant to be an enterprise only solution. > When I raised this question previously the chairs ruled, and the ADs > have concurred, that internet wide behavior (implying ISP participation) > is out of scope. Enterprise behavior is the only thing we can consider. Maybe the ADs disagree, but I don't think this flies, for several reasons: One is that IETF has a long history of requiring that its protocols work at Internet scale, even if they are only intended for use within an=20 enterprise network. For instance, we require that protocols have robust authentication even if they're generally expected to be used only behind firewalls. Another is that even if a protocol is only intended to be used on an=20 enterprise network, it will necessarily be installed on large numbers of hosts that are occasionally plugged into other networks, and the=20 security implications of this need to be examined. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:25:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuePu-0002SQ-CV; Wed, 13 Dec 2006 19:25:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuePt-0002SK-1q for nea@ietf.org; Wed, 13 Dec 2006 19:25:41 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuePr-0005pf-NX for nea@ietf.org; Wed, 13 Dec 2006 19:25:41 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 9318FA7112; Wed, 13 Dec 2006 16:25:35 -0800 (PST) Message-ID: <4580993D.1070405@deployingradius.com> Date: Wed, 13 Dec 2006 16:22:21 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Mike Fratto wrote: > I think I can safely say that the purpose of NAC is NOT to impose > anything on a host. The purpose of NAC is to allow a network owner to > control access to it's resources, which is well within the network > owner's right. Nothing more and nothing less. If a host is not upto > snuff and the network owner requires certain actions to take place, > the host can *choose* not to participate in the network. There is no > forcing anything. So you're saying that the NEA protocol is informative: a) client informs server what it has b) server informs client what to do in order to gain network access c) client does it, and is on the net, OR doesn't, and is kicked off. > I can't speak for the IETF at large, but off the top of my noggin here > are some other examples of potentially draconian standards, The "draconian standards" you reference are all informative, as outlined above. The issue with the NEA discussions is that NEA has been claimed to allow arbitrary open-ended *queries* of the end host. Since you said above that NEA isn't about open-ended queries, I don't think there's a need for more discussion on that point. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:27:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueRE-0003Ix-Lc; Wed, 13 Dec 2006 19:27:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueRD-0003Ij-71 for nea@ietf.org; Wed, 13 Dec 2006 19:27:03 -0500 Received: from nz-out-0506.google.com ([64.233.162.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GueRC-00065e-14 for nea@ietf.org; Wed, 13 Dec 2006 19:27:03 -0500 Received: by nz-out-0506.google.com with SMTP id z6so193662nzd for ; Wed, 13 Dec 2006 16:27:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oYpG49z7RLPG454PAyYTGqfr44fTisy5wOa/Hxy4rwqhlQNCDsZzuryUQVYU475ia8FcVdvu4VGGy6u10PJ/d7R+jf3wDJqzzzGVBH1m6fXkysJPOR1CNyyrAMhiFEfOAHy6wSW/u9z1xqXckLaRNgDWbOrwVnRDXOdn62Mt2AE= Received: by 10.65.219.2 with SMTP id w2mr317486qbq.1166056021585; Wed, 13 Dec 2006 16:27:01 -0800 (PST) Received: by 10.65.158.12 with HTTP; Wed, 13 Dec 2006 16:27:01 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 19:27:01 -0500 From: "Mike Fratto" To: "Alan DeKok" Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements In-Reply-To: <4580973D.6010106@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <45807FC4.7090706@deployingradius.com> <4580973D.6010106@deployingradius.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > I can see it. I just can't see how you can say you're not assuming > certain technologies, and then in the same message, refer to > pre-existing technologies as normitive references for NEA terminology > and operation. I never said they were normative references. Never even suggested it. I never even made a claim about thier worth and I said they are examples of pre-existing work. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:27:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueRH-0003LG-TI; Wed, 13 Dec 2006 19:27:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueRG-0003KD-2s for nea@ietf.org; Wed, 13 Dec 2006 19:27:06 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GueRE-00065v-NU for nea@ietf.org; Wed, 13 Dec 2006 19:27:06 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Wed, 13 Dec 2006 16:27:04 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.24; Wed, 13 Dec 2006 16:27:03 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.26]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Wed, 13 Dec 2006 16:27:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Fwd: [Nea] Re: use of a design team to develop requirements Date: Wed, 13 Dec 2006 16:26:14 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Fwd: [Nea] Re: use of a design team to develop requirements Thread-Index: AccfFPSINZE2Ds7bS6mnKjRjYU+adwAADG3AAAA8VNA= References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu><457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <45807FC4.7090706@deployingradius.com><45808BDB.4050108@cs.utk.edu><45809788.1060109@cs.utk.edu> From: Khaja Ahmed To: Khaja Ahmed , Keith Moore X-OriginalArrivalTime: 14 Dec 2006 00:27:03.0431 (UTC) FILETIME=[93E46970:01C71F16] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I should add... in the meantime, our discussion on the group, in this thread, should be consistent with the charter. You should start a separate thread requesting charter revision if you intend to pursue that. =20 Khaja -----Original Message----- From: Khaja Ahmed [mailto:khaja@windows.microsoft.com]=20 Sent: Wednesday, December 13, 2006 4:19 PM To: Keith Moore Cc: nea@ietf.org Subject: RE: Fwd: [Nea] Re: use of a design team to develop requirements I appealed to the chairs and the AD. Their position was that the charter should not be changed and it is what it is. So, whether it flies or not, this is what we are stuck with for now. If you have some way of changing that, I would love to see internet wide back in scope. Khaja -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Wednesday, December 13, 2006 4:15 PM To: Khaja Ahmed Cc: nea@ietf.org Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements > [Khaja] it is not the goals of this WG to produce and protocol that > scales to the internet. This is meant to be an enterprise only solution. > When I raised this question previously the chairs ruled, and the ADs > have concurred, that internet wide behavior (implying ISP participation) > is out of scope. Enterprise behavior is the only thing we can consider. Maybe the ADs disagree, but I don't think this flies, for several reasons: One is that IETF has a long history of requiring that its protocols work at Internet scale, even if they are only intended for use within an=20 enterprise network. For instance, we require that protocols have robust authentication even if they're generally expected to be used only behind firewalls. Another is that even if a protocol is only intended to be used on an=20 enterprise network, it will necessarily be installed on large numbers of hosts that are occasionally plugged into other networks, and the=20 security implications of this need to be examined. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:35:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueZq-0007g6-1i; Wed, 13 Dec 2006 19:35:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GueZp-0007fy-2y for nea@ietf.org; Wed, 13 Dec 2006 19:35:57 -0500 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GueZn-0007N5-SS for nea@ietf.org; Wed, 13 Dec 2006 19:35:57 -0500 Received: by nz-out-0506.google.com with SMTP id z6so194600nzd for ; Wed, 13 Dec 2006 16:35:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=P7RW3rXRZSXNNHN1ziCBrG7FbjOg1FBtxPliObLfKjlA5ENCTf/A6bfVisRiu202//X8BBuiGopWfmIhqK1ngW7Ebp0r+OYQUp4nrzXrJ36N0rpdpV3tMSE1yc+5C0lN5PK7r6+ZSfqYAOe4Arv0YBKiSHQcXLxW/v/blHi9GPU= Received: by 10.65.54.9 with SMTP id g9mr451503qbk.1166056554895; Wed, 13 Dec 2006 16:35:54 -0800 (PST) Received: by 10.65.158.12 with HTTP; Wed, 13 Dec 2006 16:35:54 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 19:35:54 -0500 From: "Mike Fratto" To: "Alan DeKok" Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements In-Reply-To: <4580993D.1070405@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <4580993D.1070405@deployingradius.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org On 12/13/06, Alan DeKok wrote: > Mike Fratto wrote: > > I think I can safely say that the purpose of NAC is NOT to impose > > anything on a host. The purpose of NAC is to allow a network owner to > > control access to it's resources, which is well within the network > > owner's right. Nothing more and nothing less. If a host is not upto > > snuff and the network owner requires certain actions to take place, > > the host can *choose* not to participate in the network. There is no > > forcing anything. > > So you're saying that the NEA protocol is informative: > > a) client informs server what it has > b) server informs client what to do in order to gain network access > c) client does it, and is on the net, OR doesn't, and is kicked off. Ok, I guess I will play the role of charter police. As it stands, the NEA is concerned with a). Not b) (that falls to remediation) and not c). Please, correct me if I am wrong. > Since you said above that NEA isn't about open-ended queries, I don't > think there's a need for more discussion on that point. I did not say that. Read the thread again. In fact, I am completely convinced that the threat that NEA, or any NAC framework, will be used for open ended queries is groundless. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:39:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuedC-0000ne-DN; Wed, 13 Dec 2006 19:39:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuedB-0000l7-8D for nea@ietf.org; Wed, 13 Dec 2006 19:39:25 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gued8-0007xz-TM for nea@ietf.org; Wed, 13 Dec 2006 19:39:25 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 4C73FA7112; Wed, 13 Dec 2006 16:39:18 -0800 (PST) Message-ID: <45809C79.6090309@deployingradius.com> Date: Wed, 13 Dec 2006 16:36:09 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Keith Moore Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <45808B42.8000802@cs.utk.edu> <45809601.80105@deployingradius.com> <4580985A.1000002@cs.utk.edu> In-Reply-To: <4580985A.1000002@cs.utk.edu> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Keith Moore wrote: > whether the search is illegal is irrelevant to this discussion. My point was that certain architectures of NEA are more likely to be legal than others. This knowledge should have *some* effect on the design of the solution. Why design something we know can't be deployed? > you don't need Turing completeness to be extremely invasive. for > example, a way to ask "tell me what the value of octet X at offset Y in > file Z" is sufficient to download the entire file system. Which is why *informative* protocols are much more robust than ones that perform queries. What should be a major point in these discussions is that if the network admin "owns" the end host, then he should be able to configure it to send out the information needed when the machine connects to the network. Any querying protocol is overkill, and adds nothing. So long as the protocol involves remediation, then the end host can connect to a remediation network, and download the latest rules about what information needs to be sent to the network. It then disconnects from the remediation network, and reconnects to the normal network, supplying the newly requested information. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:43:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guege-0002To-Vy; Wed, 13 Dec 2006 19:43:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guegd-0002Td-SH for nea@ietf.org; Wed, 13 Dec 2006 19:42:59 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guegc-0000Cq-II for nea@ietf.org; Wed, 13 Dec 2006 19:42:59 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 8B98EA7112; Wed, 13 Dec 2006 16:42:54 -0800 (PST) Message-ID: <45809D51.3090702@deployingradius.com> Date: Wed, 13 Dec 2006 16:39:45 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <4580993D.1070405@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Mike Fratto wrote: >> a) client informs server what it has >> b) server informs client what to do in order to gain network access >> c) client does it, and is on the net, OR doesn't, and is kicked off. > > Ok, I guess I will play the role of charter police. As it stands, the > NEA is concerned with a). Not b) (that falls to remediation) and not > c). Please, correct me if I am wrong. That sounds good to me. > I did not say that. Read the thread again. In fact, I am completely > convinced that the threat that NEA, or any NAC framework, will be used > for open ended queries is groundless. Should we say that a requirement for NEA is that open-ended qeuries are unnecessary, and therefore shouldn't be included? I like that. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:47:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guekq-0004zr-Vc; Wed, 13 Dec 2006 19:47:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guekq-0004zl-Iy for nea@ietf.org; Wed, 13 Dec 2006 19:47:20 -0500 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guekp-0000jq-Cq for nea@ietf.org; Wed, 13 Dec 2006 19:47:20 -0500 Received: by nz-out-0506.google.com with SMTP id z6so195681nzd for ; Wed, 13 Dec 2006 16:47:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QNnddaYjqT5okDnAHgYqd0OA9B+4pgS1G4CP5WGioRC1oHq5rpRgsOvXLKqevFnxIGnZOGHvyE9vfuwCO6cLbqGrgBn3/8pZLXbHkRm0AYwTmJSHUun/e1c+29X4PZFX1f2HiXT3CzHJGmSwmP+dCign8fwNFKcXrOQqrKxYOxQ= Received: by 10.65.237.1 with SMTP id o1mr376331qbr.1166057238911; Wed, 13 Dec 2006 16:47:18 -0800 (PST) Received: by 10.65.158.12 with HTTP; Wed, 13 Dec 2006 16:47:18 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 19:47:18 -0500 From: "Mike Fratto" To: "Alan DeKok" Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements In-Reply-To: <45809D51.3090702@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <4580993D.1070405@deployingradius.com> <45809D51.3090702@deployingradius.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > > I did not say that. Read the thread again. In fact, I am completely > > convinced that the threat that NEA, or any NAC framework, will be used > > for open ended queries is groundless. > > Should we say that a requirement for NEA is that open-ended qeuries > are unnecessary, and therefore shouldn't be included? > > I like that. Me too. :) _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:49:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuenN-0006rs-HQ; Wed, 13 Dec 2006 19:49:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuenM-0006pv-7E for nea@ietf.org; Wed, 13 Dec 2006 19:49:56 -0500 Received: from nz-out-0506.google.com ([64.233.162.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuenL-000149-19 for nea@ietf.org; Wed, 13 Dec 2006 19:49:56 -0500 Received: by nz-out-0506.google.com with SMTP id z6so195879nzd for ; Wed, 13 Dec 2006 16:49:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qPwqvA/LFjN8eZ5mGJaiSPuA6ZTySsruFD13+z9PvY5hiL5c5Njbdsld6WTlHqAsWSiO2Boxn90GrDuoNBkx/DczbmMeUTBKg0YIHsLFAd/KmOAGfhZ/xx9w6RKFcHJ2jVwywlZOnhPsAWvGjYosS6roVN+SkoeBWXJmjtHujXY= Received: by 10.65.234.3 with SMTP id l3mr451811qbr.1166057394678; Wed, 13 Dec 2006 16:49:54 -0800 (PST) Received: by 10.65.158.12 with HTTP; Wed, 13 Dec 2006 16:49:54 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 19:49:54 -0500 From: "Mike Fratto" To: "Alan DeKok" Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements In-Reply-To: <45809C79.6090309@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <45808B42.8000802@cs.utk.edu> <45809601.80105@deployingradius.com> <4580985A.1000002@cs.utk.edu> <45809C79.6090309@deployingradius.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > Which is why *informative* protocols are much more robust than ones > that perform queries. > > What should be a major point in these discussions is that if the > network admin "owns" the end host, then he should be able to configure > it to send out the information needed when the machine connects to the > network. Ok, that makes sense as a starting point. > Any querying protocol is overkill, and adds nothing. Then what does the network owner do with an unmanged host (one that is not owned by the network owner)? Something has to be done, what is the requirement? I don't know. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 19:54:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gueru-0000IR-PW; Wed, 13 Dec 2006 19:54:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Guert-0000IH-LJ for nea@ietf.org; Wed, 13 Dec 2006 19:54:37 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Guerr-0001gd-Ei for nea@ietf.org; Wed, 13 Dec 2006 19:54:37 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 617FCFDBA; Wed, 13 Dec 2006 19:54:29 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiIIgB2DavCi; Wed, 13 Dec 2006 19:54:24 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id BDB42FDA9; Wed, 13 Dec 2006 19:54:23 -0500 (EST) Message-ID: <4580A0C4.2000605@cs.utk.edu> Date: Wed, 13 Dec 2006 19:54:28 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <4580993D.1070405@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > In fact, I am completely > convinced that the threat that NEA, or any NAC framework, will be used > for open ended queries is groundless. since the NEA protocol does not exist yet, and there has been pushback against trying to impose requirements on the NEA protocol that would prevent it from being used for open ended queries, I fail to understand the source of your conviction. do you believe there's really interest in designing NEA in such a way that it can't be used for open ended queries? or do you just believe that it won't get used that way even if it's possible to use it that way? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 20:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufBv-0002LU-7p; Wed, 13 Dec 2006 20:15:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufBt-0002Iu-By for nea@ietf.org; Wed, 13 Dec 2006 20:15:17 -0500 Received: from nz-out-0506.google.com ([64.233.162.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GufBs-0004BW-4X for nea@ietf.org; Wed, 13 Dec 2006 20:15:17 -0500 Received: by nz-out-0506.google.com with SMTP id z6so198428nzd for ; Wed, 13 Dec 2006 17:15:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lLyiLIo3AY8yJzOagykGgktcwSvF6X9rNUbbH74ajpDuGw5AFUUr4QAEzs9vezEOs5uq9fTMLgkFkxVXuE/NfubZdFienVS6MWalfxAhLykD7tk8TnMhK4vazc8QtfZk4CtKGsCAyk/ZVKf+o4NHEQwt/WHiw/7EGeFAcxgA7bo= Received: by 10.65.236.14 with SMTP id n14mr481162qbr.1166058915601; Wed, 13 Dec 2006 17:15:15 -0800 (PST) Received: by 10.65.158.12 with HTTP; Wed, 13 Dec 2006 17:15:15 -0800 (PST) Message-ID: Date: Wed, 13 Dec 2006 20:15:15 -0500 From: "Mike Fratto" To: "Keith Moore" Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements In-Reply-To: <4580A0C4.2000605@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org On 12/13/06, Keith Moore wrote: > > In fact, I am completely > > convinced that the threat that NEA, or any NAC framework, will be used > > for open ended queries is groundless. > > since the NEA protocol does not exist yet, and there has been pushback > against trying to impose requirements on the NEA protocol that would > prevent it from being used for open ended queries, I fail to understand > the source of your conviction. If the protocol can be designed that prevents open ended queries while still allowing queries, then I think doing so probably makes a cleaner protocol and any mitigation to the claimed privacy threat is a side-effect. > do you believe there's really interest in designing NEA in such a way > that it can't be used for open ended queries? or do you just believe > that it won't get used that way even if it's possible to use it that way? I believe there is interest in the working group to design a robust protocol. That may mean a protocol that can't be used for open-ended queries. Any protocol could be used for nefarious purposes. I don't think that there is need for alarm that the work of the NEA will be abused any more than any other protocol. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 20:21:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufHp-0006B6-Ve; Wed, 13 Dec 2006 20:21:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufHo-0006Av-Vs for nea@ietf.org; Wed, 13 Dec 2006 20:21:24 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GufHn-0005CE-Pe for nea@ietf.org; Wed, 13 Dec 2006 20:21:24 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 8C0B9FCF7; Wed, 13 Dec 2006 20:21:17 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntp+IR+DAzuF; Wed, 13 Dec 2006 20:21:13 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id EE515FCEA; Wed, 13 Dec 2006 20:21:12 -0500 (EST) Message-ID: <4580A70D.6020302@cs.utk.edu> Date: Wed, 13 Dec 2006 20:21:17 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > Any protocol could be used for nefarious purposes. I don't think that > there is need for alarm that the work of the NEA will be abused any > more than any other protocol. well, you may have a very different view of NEA than I do. it is clear to me that a protocol that meets NEA's description could be designed in such a way as to be dangerous to hosts' and users' privacy, and that a protocol that was dangerous in such a way would give network operators more flexibility. I don't think the comparison with 'any other protocol' is valid because some protocols have much more potential for abuse than others. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 20:21:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufHr-0006ES-7F; Wed, 13 Dec 2006 20:21:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufHq-0006Ca-IM for nea@ietf.org; Wed, 13 Dec 2006 20:21:26 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GufHp-0005CI-6G for nea@ietf.org; Wed, 13 Dec 2006 20:21:26 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 00074A7112; Wed, 13 Dec 2006 17:21:20 -0800 (PST) Message-ID: <4580A654.1040305@deployingradius.com> Date: Wed, 13 Dec 2006 17:18:12 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <45808B42.8000802@cs.utk.edu> <45809601.80105@deployingradius.com> <4580985A.1000002@cs.utk.edu> <45809C79.6090309@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Mike Fratto wrote: >> Any querying protocol is overkill, and adds nothing. > > Then what does the network owner do with an unmanged host (one that is > not owned by the network owner)? Something has to be done, what is the > requirement? I don't know. Do what people do today: deny network access, OR put them into a quarantine network. They may have limited access to the Internet, but may be denied access to the corporate network. But that's assuming "unmanaged" means "non-NEA aware desktop". I don't envision switches implementing NEA any time soon, so they may be labelled "unmanaged", too. Again, this is where requirements and architecture come in. The whole PA/PB/etc. thing is nice, but ultimately it comes down to a cable being plugged into a network device. Keeping the conversation related to physical devices means that it's easier to stay focussed. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 20:22:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufJ9-0007Cm-N7; Wed, 13 Dec 2006 20:22:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GufJ8-0007Cg-Ot for nea@ietf.org; Wed, 13 Dec 2006 20:22:46 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GufJ7-0005Jt-Gu for nea@ietf.org; Wed, 13 Dec 2006 20:22:46 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id AF1F8FD00; Wed, 13 Dec 2006 20:22:39 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0LouFgk6pqG; Wed, 13 Dec 2006 20:22:32 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 40131FCF6; Wed, 13 Dec 2006 20:22:32 -0500 (EST) Message-ID: <4580A75D.5020609@cs.utk.edu> Date: Wed, 13 Dec 2006 20:22:37 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Alan DeKok Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <45808B42.8000802@cs.utk.edu> <45809601.80105@deployingradius.com> <4580985A.1000002@cs.utk.edu> <45809C79.6090309@deployingradius.com> In-Reply-To: <45809C79.6090309@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org >> whether the search is illegal is irrelevant to this discussion. > > My point was that certain architectures of NEA are more likely to be > legal than others. This knowledge should have *some* effect on the > design of the solution. Why design something we know can't be deployed? okay, I think I see your point. >> you don't need Turing completeness to be extremely invasive. for >> example, a way to ask "tell me what the value of octet X at offset Y in >> file Z" is sufficient to download the entire file system. > > Which is why *informative* protocols are much more robust than ones > that perform queries. the word "informative" seems rather vague. > What should be a major point in these discussions is that if the > network admin "owns" the end host, then he should be able to configure > it to send out the information needed when the machine connects to the > network. Any querying protocol is overkill, and adds nothing. > > So long as the protocol involves remediation, then the end host can > connect to a remediation network, and download the latest rules about > what information needs to be sent to the network. It then disconnects > from the remediation network, and reconnects to the normal network, > supplying the newly requested information. somehow I think the concept of a remediation network really should be out of scope for the NEA discussion. we understand that this is one way that NEA might be used, of course, but the idea that there should be a separate remediation network seems very shortsighted from an architectural perspective. also, in some cases (zero-day exploits) remediation may not be immediately possible. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 13 22:23:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuhCJ-000856-M8; Wed, 13 Dec 2006 22:23:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuhCI-00083t-VM for nea@ietf.org; Wed, 13 Dec 2006 22:23:50 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuhCE-0007dp-79 for nea@ietf.org; Wed, 13 Dec 2006 22:23:50 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 58665A7112; Wed, 13 Dec 2006 19:23:38 -0800 (PST) Message-ID: <4580C2F9.2070100@deployingradius.com> Date: Wed, 13 Dec 2006 19:20:25 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Keith Moore Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <4579EDA2.1050104@cs.utk.edu> <457ECD5D.8040906@cs.utk.edu> <457F059C.2010200@deployingradius.com> <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <45808B42.8000802@cs.utk.edu> <45809601.80105@deployingradius.com> <4580985A.1000002@cs.utk.edu> <45809C79.6090309@deployingradius.com> <4580A75D.5020609@cs.utk.edu> In-Reply-To: <4580A75D.5020609@cs.utk.edu> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Keith Moore wrote: >> Which is why *informative* protocols are much more robust than ones >> that perform queries. > > the word "informative" seems rather vague. I'm trying to come up with useful vocabulary for behaviors that aren't currently well described. What I mean is that many IETF protocols involve the client sending a list of attributes/values to a server, which thinks about the data, and sends a response. I've called this "informative", in that the client informs the server of what it has, and the server informs the client of the response. PPP, RADIUS, and many other protocols work like this. There is no explicit query in the protocol (which is currently an ongoing problem in RADIUS). Contrast those protocols with LDAP or SQL, where the intent is to permit nearly arbitrary queries. > somehow I think the concept of a remediation network really should be > out of scope for the NEA discussion. we understand that this is one way > that NEA might be used, of course, but the idea that there should be a > separate remediation network seems very shortsighted from an > architectural perspective. also, in some cases (zero-day exploits) > remediation may not be immediately possible. Yes. Remediation can be done as part of gaining network access (you're at patchlevel X? Here's patch Y...), but existing network access protocols can't carry arbitrary amounts of data. So some kind of network access is required to perform remediation, but they can't be allowed on the network until they have gone through the remediation process. But I do *not* think it's desirable or even useful to design NEA such that it can carry arbitrary amounts of data for remediation. We already have too many network protocols that have turned into IP tunnels. And for zero-day exploits, shutting down the network may be cheaper than having it destroyed by an attacker. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Dec 18 12:33:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMML-0007GX-I8; Mon, 18 Dec 2006 12:33:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwMMK-0007Em-Dt for nea@ietf.org; Mon, 18 Dec 2006 12:33:04 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwMMF-0007Ey-WC for nea@ietf.org; Mon, 18 Dec 2006 12:33:04 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 14A76A7121; Mon, 18 Dec 2006 09:32:53 -0800 (PST) Message-ID: <4586D002.3050800@deployingradius.com> Date: Mon, 18 Dec 2006 09:29:38 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: [Nea] Re: use of a design team to develop requirements References: <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Mike Fratto wrote: > If the protocol can be designed that prevents open ended queries while > still allowing queries, What kind of queries? Do you have examples? And I still don't see why *any* queries are required. Look at the target deployments specified by the charter, the enterprise admin "owns" the machines. So there is *always* a way for that admin to inform the machines off-line what information is required. This can be done when the machines are first configured, or as part of a remediation update. i.e. remediation updates inform the machines of updates to local site policy. Updates to virus scanners, etc. are just subsets of updates to the local site policy. The updates will also include statements sycg as "install new software program X, and when you reconnect, tell me what it says." Requiring queries in the NEA protocol looks to me like the intended deployment scenarios are *outside* of the scenarios described in the charter. > Any protocol could be used for nefarious purposes. I don't think that > there is need for alarm that the work of the NEA will be abused any > more than any other protocol. Most network access protocols (PPP, DHCP, RADIUS, etc.) do NOT support queries. If the NEA protocol supports queries, it *will* be abused more than protocols that do not support queries. That conclusion is inescapable: The more functionality exists in a protocol, the more potential for abuse. We should therefore be careful to put only required functionality into NEA, and nothing more. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Dec 18 14:28:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOAH-0004I3-VM; Mon, 18 Dec 2006 14:28:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOAH-0004Hy-03 for nea@ietf.org; Mon, 18 Dec 2006 14:28:45 -0500 Received: from smtp.mail.umich.edu ([141.211.14.82] helo=hellskitchen.mr.itd.umich.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwOAF-00011J-MU for nea@ietf.org; Mon, 18 Dec 2006 14:28:44 -0500 Received: FROM [10.2.20.62] (LIN1-118-38-220.ciena.com [63.118.38.220]) BY hellskitchen.mr.itd.umich.edu ID 4586EBAB.DD493.16252 ; 18 Dec 2006 14:27:40 -0500 In-Reply-To: <4586D002.3050800@deployingradius.com> References: <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Vollbrecht Subject: Re: [Nea] Re: use of a design team to develop requirements Date: Mon, 18 Dec 2006 14:27:38 -0500 To: Alan DeKok X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: Keith Moore , nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org On Dec 18, 2006, at 12:29 PM, Alan DeKok wrote: > Mike Fratto wrote: > >> If the protocol can be designed that prevents open ended queries >> while >> still allowing queries, > > What kind of queries? Do you have examples? > > And I still don't see why *any* queries are required. Look at the > target deployments specified by the charter, the enterprise admin > "owns" > the machines. So there is *always* a way for that admin to inform the > machines off-line what information is required. This can be done when > the machines are first configured, or as part of a remediation update. > > i.e. remediation updates inform the machines of updates to local > site > policy. Updates to virus scanners, etc. are just subsets of > updates to > the local site policy. The updates will also include statements > sycg as > "install new software program X, and when you reconnect, tell me > what it > says." > > Requiring queries in the NEA protocol looks to me like the intended > deployment scenarios are *outside* of the scenarios described in the > charter. > I have assumed that the network could require information to allow access. The user could also refuse to provided certain information. The result on the network side might be to allow only access to a remediation network. The result on the user side might be to only allow the user to connect to a particular web site. The point is that policy exists at both places. The value of queries to at least some people is the reason for the wg. >> Any protocol could be used for nefarious purposes. I don't think that >> there is need for alarm that the work of the NEA will be abused any >> more than any other protocol. > > Most network access protocols (PPP, DHCP, RADIUS, etc.) do NOT > support queries. If the NEA protocol supports queries, it *will* be > abused more than protocols that do not support queries. > > That conclusion is inescapable: The more functionality exists in a > protocol, the more potential for abuse. We should therefore be > careful > to put only required functionality into NEA, and nothing more. > > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Dec 18 15:09:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOnK-0002zW-JF; Mon, 18 Dec 2006 15:09:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwOnJ-0002zI-L3 for nea@ietf.org; Mon, 18 Dec 2006 15:09:05 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwOnI-00073D-5O for nea@ietf.org; Mon, 18 Dec 2006 15:09:05 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 5BC11A70BA; Mon, 18 Dec 2006 12:09:01 -0800 (PST) Message-ID: <4586F499.10101@deployingradius.com> Date: Mon, 18 Dec 2006 12:05:45 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Mike Fratto , nea@ietf.org Subject: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Mike Fratto wrote: > Queries that ask the client to tell the authorization server about > itself such as: ... If the clients are "managed" as you say, then the queries aren't necessary, as I pointed out earlier. If the clients aren't managed, then I still think the queries aren't necessary. > I think you are making the assumption that the only use of NEA is to > allow *managed computers* (meaning computers under the direct control > of the network owner) to attach the network. That is one use case. Agreed, and I think it's the main use-case. > The other use case is allowing unmanaged computers access to the > network. Examples of unmanaged computers are temporary workers like > contractors and consultants, sales people, and on-site support--people > who are not employees, but need network access. Agreed. But... do they need unfettered access to the internals of the enterprise network? Why not just drop them into a quarantine zone, or maybe filter/block most of their traffic? This can be done today without the use of NEA, so I'm not sure what value-add NEA has. > Or you are making the assumtion that ALL computers owned or not-owned > will run NEA clients, which is unwarranted. No, I've stated repeatedly on this list than machines not running NEA are expected to connect to the network, and that there are methods for dealing with those machines. > OK, perhaps not explicity, but implicitly. PPP negotiations converge > because the peers try to determine a common set of parameters that > they want set and the attributes assigned to them. DHCP clients want > to set/get specific attributes, etc. The point is you can discover > some interesting things about a network via PPP and DHCP. Discovery is not the same as query. The issue is one of trust and security. For unmanaged machines, neither client nor server trust each other. As an NEA client, why would you volunteer that you're running product X at version Y? There might be an exploit you don't know about, and the NEA server might just use its knowledge of that exploit to attack you. The only "queries" I see as being useful from NEA server to client are statements like "prove to me that product X is up to date". The client can supply a certificate (like Doug O suggests), that the server can validate with the manufacturer of product X. But in no way does this mean that the certificate has to *publicly* state which version of product X is installed. There's simply no need for the NEA server to know that information. In fact, the NEA server has little use for that information to make any decision independent of the manufacturer of product X. If the NEA server gets told product X is at version Y, what does that mean? Is it a good thing? Is that version vulnerable? Is it newer than the version the NEA server knows about? The only way to know is to ask the manufacturer, which means that there's no reason for the NEA server to know detailed product information about what's running on the client. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Dec 18 15:24:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwP2b-0008W2-Hd; Mon, 18 Dec 2006 15:24:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwP2a-0008Vu-62 for nea@ietf.org; Mon, 18 Dec 2006 15:24:52 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwP2Y-0001Ea-SI for nea@ietf.org; Mon, 18 Dec 2006 15:24:52 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id EBF79A70BA; Mon, 18 Dec 2006 12:24:47 -0800 (PST) Message-ID: <4586F84E.1030605@deployingradius.com> Date: Mon, 18 Dec 2006 12:21:34 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: John Vollbrecht Subject: NEA requirements (was Re: [Nea] Re: use of a design team to develop requirements) References: <45804574.9040400@deployingradius.com> <20061213155159.b457af48.moore@cs.utk.edu> <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Keith Moore , nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org John Vollbrecht wrote: > I have assumed that the network could require information to allow > access. What kind of information? Why? What will the NEA server do with that information once it receives it? When I work through the various scenarios, I don't see much use for queries. > The user could also refuse to provided certain information. > The result on the network side might be to allow only access to a > remediation network. The result on the user side might be to only allow > the user to connect to a particular web site. The point is that policy > exists at both places. Of course. > The value of queries to at least some people is the reason for the wg. That's nice. Do you have *concrete* examples that we can talk about? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Dec 18 16:52:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQPS-0000dO-Bw; Mon, 18 Dec 2006 16:52:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQPQ-0000ck-PN for nea@ietf.org; Mon, 18 Dec 2006 16:52:32 -0500 Received: from mga09.intel.com ([134.134.136.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwQP4-0000CD-CZ for nea@ietf.org; Mon, 18 Dec 2006 16:52:11 -0500 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga09.intel.com with ESMTP; 18 Dec 2006 13:52:07 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga002.fm.intel.com with ESMTP; 18 Dec 2006 13:52:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.12,185,1165219200"; d="scan'208"; a="28371989:sNHT19117314" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Dec 2006 13:52:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NEA requirements (was Re: [Nea] Re: use of a design team to developrequirements) Date: Mon, 18 Dec 2006 16:51:57 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056011D1227@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA requirements (was Re: [Nea] Re: use of a design team to developrequirements) thread-index: Acci4qD7TqMIPU2IRVK1UZf9EKk/MQACjTUg From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 18 Dec 2006 21:52:07.0004 (UTC) FILETIME=[C2DAF9C0:01C722EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org >> I have assumed that the network could require information >> to allow access. > > What kind of information? Why? What will the NEA > server do with that information once it receives it? NEA server probably couldn't care less for what kind of information it is transferring. Policy-driven. As long as there is NEA agent (or clent) on the=20 supplicant machine, it can pass whatever info it deems right. So practically - as long as either the NEA client or the relevant plug-in that talks to it, can get the information that the server requests - that=20 piece of data will cross the wire.=20 > When I work through the various scenarios, > I don't see much use for queries. Whether there is a "chatter", is unclear.=20 Perhaps NEA server will be able to mention everything it=20 wants in one request, and the client might be able to=20 pack all the data into one response. Or perhaps NEA client will just shove everything it can get about the system and send it in one bunch, without being specific - in response to a generic request. Perhaps based upon the first response to small and generic query,=20 the server will choose to send more specific queries to learn=20 about some particulars of the client machine. >> The user could also refuse to provided certain information.=20 >> The result on the network side might be to allow only access >> to a remediation network.=20 An old example: "Customer doesn't have to provide his=20 Social Security number, the bank doesn't have to grant=20 the loan." :-) >> The result on the user side might be to only allow >> the user to connect to a particular web site.=20 >> The point is that policy exists at both places. > > Of course. What's that "second place" where the policy exists? >> The value of queries to at least some people is the >> reason for the wg. > > That's nice. Do you have *concrete* examples that > we can talk about? Me too :-) Do you mean a small set of generic posture attributes that=20 every host is supposed to carry?=20 Regardless, it doesn't seem to be the main focus of this WG. :-) _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Dec 18 17:06:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQd3-0008MV-Lh; Mon, 18 Dec 2006 17:06:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwQd1-0008Ly-Sy for nea@ietf.org; Mon, 18 Dec 2006 17:06:35 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwQd0-0002La-Hi for nea@ietf.org; Mon, 18 Dec 2006 17:06:35 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 57BB5A70BA; Mon, 18 Dec 2006 14:06:31 -0800 (PST) Message-ID: <45871026.3000604@deployingradius.com> Date: Mon, 18 Dec 2006 14:03:18 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Blumenthal, Uri" Subject: Re: NEA requirements (was Re: [Nea] Re: use of a design team to developrequirements) References: <279DDDAFA85EC74C9300A0598E704056011D1227@hdsmsx412.amr.corp.intel.com> In-Reply-To: <279DDDAFA85EC74C9300A0598E704056011D1227@hdsmsx412.amr.corp.intel.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Blumenthal, Uri wrote: > Perhaps NEA server will be able to mention everything it > wants in one request, and the client might be able to > pack all the data into one response. Or perhaps NEA > client will just shove everything it can get about > the system and send it in one bunch, without being > specific - in response to a generic request. What I see is something along the following lines: Client -> Server: I'm client FOO Server -> Client: I'm network BAR Client -> Server: Here's my posture information for BAR ... > Perhaps based upon the first response to small and generic query, > the server will choose to send more specific queries to learn > about some particulars of the client machine. Again, I don't see a need for this. Ever. >>> The result on the user side might be to only allow >>> the user to connect to a particular web site. >>> The point is that policy exists at both places. >> Of course. > > What's that "second place" where the policy exists? The client. It can be configured to tell network A one thing, and network B another. e.g. It tells my workplace that its virus scanner is up to date, but doesn't tell my broadband provider that information. > Do you mean a small set of generic posture attributes that > every host is supposed to carry? > Regardless, it doesn't seem to be the main focus of this WG. :-) It seems so. I would like to start off knowing use-cases, scenarios, and the intent of the administrator. From that, we determine what information is needed in order for the administrator to make an informed decision. We then determine how to design a protocol that carries that information. i.e. *concrete* use-cases. "Assessing posture" is a nice phrase, but I don't know how it translates to real-world decisions. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Dec 18 17:38:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwR7e-0005gj-Bc; Mon, 18 Dec 2006 17:38:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwR7c-0005ge-KB for nea@ietf.org; Mon, 18 Dec 2006 17:38:12 -0500 Received: from mail1.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwR7Z-0000Yr-Nb for nea@ietf.org; Mon, 18 Dec 2006 17:38:12 -0500 Received: from TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 18 Dec 2006 14:38:09 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by TK5-EXHUB-C101.redmond.corp.microsoft.com (157.54.70.76) with Microsoft SMTP Server id 8.0.685.24; Mon, 18 Dec 2006 14:36:51 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2825); Mon, 18 Dec 2006 14:36:52 -0800 x-mimeole: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: NEA requirements (was Re: [Nea] Re: use of a design teamto developrequirements) Date: Mon, 18 Dec 2006 14:36:49 -0800 Message-ID: In-Reply-To: <45871026.3000604@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA requirements (was Re: [Nea] Re: use of a design teamto developrequirements) Thread-Index: Acci8NEFbe+ijK84QVS83nVa8zIhhwAAyj+A References: <279DDDAFA85EC74C9300A0598E704056011D1227@hdsmsx412.amr.corp.intel.com> <45871026.3000604@deployingradius.com> From: Khaja Ahmed To: Alan DeKok , "Blumenthal, Uri" X-OriginalArrivalTime: 18 Dec 2006 22:36:52.0052 (UTC) FILETIME=[0344C940:01C722F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I think the approach that Alan outlines is a pretty reasonable one. I too see no reason for a query/response based protocol. In fact a query response based protocol is only likely to add needless complexity and make the scheme susceptible to abuse. =20 Based on the identity of the network, the machine will communicate the state necessary to gain (or be denied) admission. With appropriate key management and federated trust mechanisms in place the information can also be encrypted so only authorized networks can get / see the information. =20 Khaja -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Monday, December 18, 2006 2:03 PM To: Blumenthal, Uri Cc: nea@ietf.org Subject: Re: NEA requirements (was Re: [Nea] Re: use of a design teamto developrequirements) Blumenthal, Uri wrote: > Perhaps NEA server will be able to mention everything it=20 > wants in one request, and the client might be able to=20 > pack all the data into one response. Or perhaps NEA > client will just shove everything it can get about > the system and send it in one bunch, without being > specific - in response to a generic request. What I see is something along the following lines: Client -> Server: I'm client FOO Server -> Client: I'm network BAR Client -> Server: Here's my posture information for BAR ... > Perhaps based upon the first response to small and generic query,=20 > the server will choose to send more specific queries to learn=20 > about some particulars of the client machine. Again, I don't see a need for this. Ever. >>> The result on the user side might be to only allow >>> the user to connect to a particular web site.=20 >>> The point is that policy exists at both places. >> Of course. >=20 > What's that "second place" where the policy exists? The client. It can be configured to tell network A one thing, and network B another. e.g. It tells my workplace that its virus scanner is up to date, but doesn't tell my broadband provider that information. > Do you mean a small set of generic posture attributes that=20 > every host is supposed to carry?=20 > Regardless, it doesn't seem to be the main focus of this WG. :-) It seems so. I would like to start off knowing use-cases, scenarios, and the intent of the administrator. From that, we determine what information is needed in order for the administrator to make an informed decision. We then determine how to design a protocol that carries that information. i.e. *concrete* use-cases. "Assessing posture" is a nice phrase, but I don't know how it translates to real-world decisions. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Dec 18 19:05:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwSTo-0003cA-E6; Mon, 18 Dec 2006 19:05:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwSTm-0003c2-Pi for nea@ietf.org; Mon, 18 Dec 2006 19:05:10 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwSTk-0002GX-EJ for nea@ietf.org; Mon, 18 Dec 2006 19:05:10 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBJ054jC011248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Dec 2006 16:05:05 -0800 In-Reply-To: References: <279DDDAFA85EC74C9300A0598E704056011D1227@hdsmsx412.amr.corp.intel.com> <45871026.3000604@deployingradius.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: NEA requirements (was Re: [Nea] Re: use of a design teamto developrequirements) Date: Mon, 18 Dec 2006 16:05:02 -0800 To: Khaja Ahmed X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org On Dec 18, 2006, at 2:36 PM, Khaja Ahmed wrote: > I think the approach that Alan outlines is a pretty reasonable one. > I too see no reason for a query/response based protocol. In fact a > query response based protocol is only likely to add needless > complexity and make the scheme susceptible to abuse. > > Based on the identity of the network, the machine will communicate > the state necessary to gain (or be denied) admission. With > appropriate key management and federated trust mechanisms in place > the information can also be encrypted so only authorized networks > can get / see the information. Agreed. The information exchanged could represent a set of time- stamped certificates. Information contained within the certificates would be the provider and resources used. The client's version of the certificate would also indicate the status of the service. The NEA protocol could be limited to just the broker advertising in sets of desired or required certificates offering their certificates carrying their identity of "hostmaster@example.com" as the entity making the request. Having a current certificate for each required set should satisfy any acceptance requirement. When a certificate is lacking, the resources and the provider of the certificate and related service will be apparent. The resources can be verified prior to invoking any service related to remediation or questioning prior to obtaining a fresh certificate. This approach should make it easy to implement a scheme suitable for autonomous devices, or client systems that will likely closely approximate an autonomous system. The requested service might be as simple as acknowledging the provider's AUP and their current status when dealing with humans. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 08:47:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwfJm-0003pX-VV; Tue, 19 Dec 2006 08:47:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwfJl-0003pR-KI for nea@ietf.org; Tue, 19 Dec 2006 08:47:41 -0500 Received: from wr-out-0506.google.com ([64.233.184.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwfJj-0002QO-D5 for nea@ietf.org; Tue, 19 Dec 2006 08:47:41 -0500 Received: by wr-out-0506.google.com with SMTP id i7so1240628wra for ; Tue, 19 Dec 2006 05:47:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E/JhFkjAhyrRh4hfLiWE4/YSHxli9Ndx/i62bKoUTHBnyCF7EpM6veiIWiIw/HnRYxr7U18zNPYG38kWDAzQeezANa79mlfp5IpjyZXJSTN1tkB/vzdVUwoC9E9W8wcmNeo7PF++rk1PW12UCXE1kyAs0bZlfRDv9r6VoBx51l4= Received: by 10.90.51.17 with SMTP id y17mr5348179agy.1166536055094; Tue, 19 Dec 2006 05:47:35 -0800 (PST) Received: by 10.65.158.12 with HTTP; Tue, 19 Dec 2006 05:47:35 -0800 (PST) Message-ID: Date: Tue, 19 Dec 2006 08:47:35 -0500 From: "Mike Fratto" To: nea@ietf.org Subject: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org To: Alan DeKok > In fact, the NEA server has little use for that information to make > any decision independent of the manufacturer of product X. If the NEA > server gets told product X is at version Y, what does that mean? Is it > a good thing? Is that version vulnerable? Is it newer than the version > the NEA server knows about? So what does an NEA server make a decision on? It can't make a decision in a vacuum. Reporting product X, version y, update DD-MM-YYYY-hh:mm:ss, tells the NEA server the current status of that piece of software. This is used to make a decision based on local policy. The NEA server doesn't need to know about vulns or exploits. The human administring the local policy does, however. Some person has to say that products prior to version Z are unacceptable and configure a policy decision. That could be a query/response or it could be notification mechanism, though the latter is highly inflexible and severly limiting. Now ask me why. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 09:09:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwfeU-0006JM-P5; Tue, 19 Dec 2006 09:09:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwfeS-0006HP-Qw for nea@ietf.org; Tue, 19 Dec 2006 09:09:04 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwfeQ-0007T9-Ia for nea@ietf.org; Tue, 19 Dec 2006 09:09:04 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 7809556487; Tue, 19 Dec 2006 09:08:54 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82C36IRIwEB8; Tue, 19 Dec 2006 09:08:48 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 9638F56498; Tue, 19 Dec 2006 09:08:47 -0500 (EST) Message-ID: <4587F272.8020701@cs.utk.edu> Date: Tue, 19 Dec 2006 09:08:50 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org -------- Original Message -------- > To: Alan DeKok > > >> In fact, the NEA server has little use for that information to make >> any decision independent of the manufacturer of product X. If the NEA >> server gets told product X is at version Y, what does that mean? Is it >> a good thing? Is that version vulnerable? Is it newer than the version >> the NEA server knows about? > > So what does an NEA server make a decision on? who says the NEA server has to make a (nontrivial) decision? if the client presents a statement, signed by a key that is traceable to a host and a product, that says that the host conforms to a certain level of a profile, what more does the server need to do other than to tell the network to give the host whatever level of access corresponds to that profile? > That could be a query/response or it could be notification mechanism, > though the latter is highly inflexible and severly limiting. yes, but that's the point - the limitations are highly desirable in reducing the threat of NEA to privacy, and they don't get in the way of letting NEA do the job that it is designed to do. they also have the advantage of making NEA a fairly trivial protocol to design and implement, allowing the standard to get to market much more quickly. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 13:25:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwjeo-0001Wz-0e; Tue, 19 Dec 2006 13:25:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwjen-0001Wq-ID for nea@ietf.org; Tue, 19 Dec 2006 13:25:41 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwjel-0006a8-7z for nea@ietf.org; Tue, 19 Dec 2006 13:25:41 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 018D7A70BA; Tue, 19 Dec 2006 10:25:34 -0800 (PST) Message-ID: <45882DDB.6060901@deployingradius.com> Date: Tue, 19 Dec 2006 10:22:19 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Keith Moore Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> In-Reply-To: <4587F272.8020701@cs.utk.edu> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Keith Moore wrote: > who says the NEA server has to make a (nontrivial) decision? if the > client presents a statement, signed by a key that is traceable to a host > and a product, that says that the host conforms to a certain level of a > profile, what more does the server need to do other than to tell the > network to give the host whatever level of access corresponds to that > profile? Exactly. I would like to see use-cases to the contrary. If they exist, and are important, then support for queries may be useful. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 13:26:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwjfg-0003Fl-NS; Tue, 19 Dec 2006 13:26:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwjff-0003Bl-5L for nea@ietf.org; Tue, 19 Dec 2006 13:26:35 -0500 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwjfd-000784-Vw for nea@ietf.org; Tue, 19 Dec 2006 13:26:35 -0500 Received: by nz-out-0506.google.com with SMTP id z6so833600nzd for ; Tue, 19 Dec 2006 10:26:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E/jRbhG2WJaANeRYM2R2uhnCQySTsC/Xbsve4Cppj2dd079nYhc/hWEoHDIRo0snWKQbvL5rJVwaMJL22FyNe0gQD7Pasvcs/TveG8EjZPGHfGv0Hmn6EVG5SjaL/LHkP87kpX2AtVi6vvXee1iVKVaKvORlATKaYdVsesI8hvA= Received: by 10.65.151.6 with SMTP id d6mr7636171qbo.1166552793636; Tue, 19 Dec 2006 10:26:33 -0800 (PST) Received: by 10.65.158.12 with HTTP; Tue, 19 Dec 2006 10:26:33 -0800 (PST) Message-ID: Date: Tue, 19 Dec 2006 13:26:33 -0500 From: "Mike Fratto" To: "Alan DeKok" Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) In-Reply-To: <45882DDB.6060901@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > I would like to see use-cases to the contrary. If they exist, and are > important, then support for queries may be useful. What uses cases are you looking for? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 13:26:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwjg3-0003VN-CZ; Tue, 19 Dec 2006 13:26:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwjg3-0003VH-0X for nea@ietf.org; Tue, 19 Dec 2006 13:26:59 -0500 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwjg0-0007E9-P0 for nea@ietf.org; Tue, 19 Dec 2006 13:26:58 -0500 Received: by py-out-1112.google.com with SMTP id f31so1029151pyh for ; Tue, 19 Dec 2006 10:26:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qBaO9pIPdYY4yVWjK27oaLaNsMjbsqV5dXa3kUMZ6OoyBtM39QmeiJQTfNEG8Layow690mY8OCV1l2puQQgc0Si4fQmCK53KIttKj9lD50rr7Al2Rov+ynbO6VpdvSbVtu2Joa2oj3L3qyXuEI9nSQVMen5rTlKx/1gAcL9V9rI= Received: by 10.35.54.1 with SMTP id g1mr10723414pyk.1166552816521; Tue, 19 Dec 2006 10:26:56 -0800 (PST) Received: by 10.65.158.12 with HTTP; Tue, 19 Dec 2006 10:26:56 -0800 (PST) Message-ID: Date: Tue, 19 Dec 2006 13:26:56 -0500 From: "Mike Fratto" To: "Keith Moore" Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) In-Reply-To: <4587F272.8020701@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > > So what does an NEA server make a decision on? > > who says the NEA server has to make a (nontrivial) decision? who said the decision is trivial or non-trivial? I don't even know what that means. > if the > client presents a statement, signed by a key that is traceable to a host > and a product, that says that the host conforms to a certain level of a > profile, what more does the server need to do other than to tell the > network to give the host whatever level of access corresponds to that > profile? Ok, I am going to pass on the key signing for the moment. It's an implementation issue and can be discussed later. Your general point, one where the client sends a statement that it conforms to a level of profile makes sense make sense but I have two questions. 1) How do you propose the handshake happen? 2) What happens in the case where a NEA client doesn't send sufficient information to the NEA server for the NEA server to make a decision? > > > That could be a query/response or it could be notification mechanism, > > though the latter is highly inflexible and severly limiting. > > yes, but that's the point - the limitations are highly desirable in > reducing the threat of NEA to privacy, and they don't get in the way of > letting NEA do the job that it is designed to do. they also have the > advantage of making NEA a fairly trivial protocol to design and > implement, allowing the standard to get to market much more quickly. I was not referring to privacy limitations. Remember, I don't think privacy is much of an issue. The limitations in a notification mechanism is that the communication is one-way with no chance for the two system to converge. The policy decision comes down to "Did the NEA client send me what I need to know?" and "Does that fit my policy?" If the exchange fails at question 1 and there is no recourse for the NEA server to query the NEA client for more information, then the exchange ends. That is inflexible and a non-starter. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 13:44:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwjx4-0004sM-HM; Tue, 19 Dec 2006 13:44:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwjx2-0004pu-9x for nea@ietf.org; Tue, 19 Dec 2006 13:44:32 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwjwn-0003Gt-AH for nea@ietf.org; Tue, 19 Dec 2006 13:44:32 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id E15FDA70BA; Tue, 19 Dec 2006 10:44:14 -0800 (PST) Message-ID: <4588323B.9050507@deployingradius.com> Date: Tue, 19 Dec 2006 10:40:59 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Mike Fratto wrote: >> I would like to see use-cases to the contrary. If they exist, and are >> important, then support for queries may be useful. > > What uses cases are you looking for? Ones where the scenarios we presented don't work. e.g. where the NEA server needs to know about the status of something on the client, and where there's no third party involved. We'll ignore the case where the NEA server is the "third party". That scenario is identical to ones where there is a real third party. That is, if the NEA server needs more information than is supplied by any third party software, the enterprise administrator can install his own software on the NEA client. That software then uses the same methods as used by any other third parties to report posture. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 13:53:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwk5Q-0001Fg-0I; Tue, 19 Dec 2006 13:53:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwk5O-0001Fa-N1 for nea@ietf.org; Tue, 19 Dec 2006 13:53:10 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwk5M-0005VP-Fx for nea@ietf.org; Tue, 19 Dec 2006 13:53:10 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 9631056456; Tue, 19 Dec 2006 13:53:02 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFTjXl8zHiDW; Tue, 19 Dec 2006 13:52:55 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id BC22756443; Tue, 19 Dec 2006 13:52:54 -0500 (EST) Message-ID: <4588350B.9030008@cs.utk.edu> Date: Tue, 19 Dec 2006 13:52:59 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Alan DeKok Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> In-Reply-To: <45882DDB.6060901@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org -------- Original Message -------- > Keith Moore wrote: >> who says the NEA server has to make a (nontrivial) decision? if the >> client presents a statement, signed by a key that is traceable to a host >> and a product, that says that the host conforms to a certain level of a >> profile, what more does the server need to do other than to tell the >> network to give the host whatever level of access corresponds to that >> profile? > > Exactly. > > I would like to see use-cases to the contrary. If they exist, and are > important, then support for queries may be useful. I suppose that begs the question of how NEA clients learn the profiles that they need to evaluate. Does the NEA protocol need to support, or is this somebody else's problem? What if the client connects and finds that its profile is out-of-date, should NEA allow the client to download the current profile? And how different is that (from a security/privacy point-of-view) than a query? Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 13:53:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwk5e-0001XZ-6q; Tue, 19 Dec 2006 13:53:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwk5c-0001X3-Ts for nea@ietf.org; Tue, 19 Dec 2006 13:53:24 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwk5b-0005WY-Kq for nea@ietf.org; Tue, 19 Dec 2006 13:53:24 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 2E9D8A70BA; Tue, 19 Dec 2006 10:53:21 -0800 (PST) Message-ID: <4588345E.3010203@deployingradius.com> Date: Tue, 19 Dec 2006 10:50:06 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Mike Fratto wrote: > 2) What happens in the case where a NEA client doesn't send sufficient > information to the NEA server for the NEA server to make a decision? Huh? See previous posts. This has been discussed many times. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 14:17:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwkTN-0005eN-JK; Tue, 19 Dec 2006 14:17:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwkTN-0005eI-3v for nea@ietf.org; Tue, 19 Dec 2006 14:17:57 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwkTL-0002yh-NN for nea@ietf.org; Tue, 19 Dec 2006 14:17:57 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 6336156462; Tue, 19 Dec 2006 14:17:49 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZC2BA1SadoZh; Tue, 19 Dec 2006 14:17:32 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id B26905646C; Tue, 19 Dec 2006 14:17:31 -0500 (EST) Message-ID: <45883AB9.8080606@cs.utk.edu> Date: Tue, 19 Dec 2006 14:17:13 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org >> who says the NEA server has to make a (nontrivial) decision? > > who said the decision is trivial or non-trivial? I don't even know > what that means. in my mind a trivial decision would be a situation where the client software is responsible for determining whether the host conforms to the profile for that network, it simply reports this to the NEA server, and the NEA server then verifies that the profile is current and that the NEA client is trustworthy. that's why the signature, because the server would want some way to establish trust in the NEA client before granting access to the network. but in this model, the server's decision-making role is fairly "trivial" - if the signature checks out, believe whatever the client is saying and give the client whatever level of network access corresponds to that client and that profile. by contrast, a non-trivial decision would be one where the NEA server has to decide, based on several pieces of information provided by the client (say, the results of some arbitrary number of tests), what level of network access a client should have. >> if the client presents a statement, signed by a key that is >> traceable to a host and a product, that says that the host conforms >> to a certain level of a profile, what more does the server need to >> do other than to tell the network to give the host whatever level >> of access corresponds to that profile? > > Ok, I am going to pass on the key signing for the moment. It's an > implementation issue and can be discussed later. I don't think it's an implementation issue - it needs to be specified as part of the protocol. > Your general point, one where the client sends a statement that it > conforms to a level of profile makes sense make sense but I have two > questions. > > 1) How do you propose the handshake happen? It seems a bit early to do protocol design but offhand I think it would look something like this: S: I'm server , acting on behalf of network and here are my credentials. C: I'm client , and here are my credentials. S: current profile for you is . C: For network , I {do, don't} conform to profile , signed , and here are my credentials. S: You are granted access level {full, reduced, remedial, none}. C: thanks! and that would be it. Or maybe S: I'm server , acting on behalf of network and here are my credentials. C: I'm client , and here are my credentials. S: current profile for you is . C: I don't have profile S: consists of "bits..." C: bye! (with the assumption that the client then needs to take some time to evaluate that profile before attempting to connect again) and just in case it's not obvious, the profile would contain a list of tests that needed to be carried out by the client. > 2) What happens in the case where a NEA client doesn't send > sufficient information to the NEA server for the NEA server to make a > decision? In this model, there's always sufficient information provided to the server because most of the decision is made on the client, and the client just reports the result of that evaluation to the server. The server just decides whether the client's decision-making and reporting are trustworthy and gives the client the level of access that it's configured to give based on the client identity and profile. >>> That could be a query/response or it could be notification >>> mechanism, though the latter is highly inflexible and severly >>> limiting. >> >> yes, but that's the point - the limitations are highly desirable in >> reducing the threat of NEA to privacy, and they don't get in the >> way of letting NEA do the job that it is designed to do. they also >> have the advantage of making NEA a fairly trivial protocol to >> design and implement, allowing the standard to get to market much >> more quickly. > > I was not referring to privacy limitations. Remember, I don't think > privacy is much of an issue. Well, perhaps we simply disagree, or perhaps you just have in mind a different model which deals with privacy threats in a different way. But it's important to not assume that NEA will be used only by people/networks who respect users' privacy. > The limitations in a notification mechanism is that the communication > is one-way with no chance for the two system to converge. The policy > decision comes down to "Did the NEA client send me what I need to > know?" and "Does that fit my policy?" If the exchange fails at > question 1 and there is no recourse for the NEA server to query the > NEA client for more information, then the exchange ends. That is > inflexible and a non-starter. Any protocol that allows the client and server to iterate with the server demanding arbitrary information from the client is a huge privacy risk and a non-starter for that reason. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 14:59:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwl7Y-0002MP-7r; Tue, 19 Dec 2006 14:59:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwl7X-0002ME-0N for nea@ietf.org; Tue, 19 Dec 2006 14:59:27 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwl7V-0003pZ-It for nea@ietf.org; Tue, 19 Dec 2006 14:59:26 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id C7BD3A7121; Tue, 19 Dec 2006 11:59:22 -0800 (PST) Message-ID: <458843D7.3020205@deployingradius.com> Date: Tue, 19 Dec 2006 11:56:07 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Keith Moore Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> In-Reply-To: <4588350B.9030008@cs.utk.edu> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Keith Moore wrote: >> I would like to see use-cases to the contrary. If they exist, and are >> important, then support for queries may be useful. > > I suppose that begs the question of how NEA clients learn the profiles > that they need to evaluate. I think it's "via the remediation network, which is outside of the scope of NEA". > Does the NEA protocol need to support, or > is this somebody else's problem? What if the client connects and finds > that its profile is out-of-date, should NEA allow the client to download > the current profile? The server should decide if the clients profile is out of date. The alternative is the client system saying "Yeah, I'm fine... honest...", which is pretty much what we have today. > And how different is that (from a security/privacy > point-of-view) than a query? Not much, but if the system doesn't have a process for policy updates, it isn't that useful. My take is that policy updates will happen much less often than connection requests. So if nothing else, it's more efficient to not have queries at every connection attempt. Since the queries and/or policy updates may be large, it would be better to leverage real networks for that process, rather than trying to carry large amounts of data in the NEA protocol itself. I'll try to write up an I-D that summarises the discussion so far. It may be mid January before it's out, though. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 15:13:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlKm-0001lj-A4; Tue, 19 Dec 2006 15:13:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwlKk-0001lb-J3 for nea@ietf.org; Tue, 19 Dec 2006 15:13:06 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwlKj-0006ye-AM for nea@ietf.org; Tue, 19 Dec 2006 15:13:06 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id E840256474; Tue, 19 Dec 2006 15:12:58 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQHNz71oYztW; Tue, 19 Dec 2006 15:12:46 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 7A92756450; Tue, 19 Dec 2006 15:12:46 -0500 (EST) Message-ID: <458847C2.7060808@cs.utk.edu> Date: Tue, 19 Dec 2006 15:12:50 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Alan DeKok Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> In-Reply-To: <458843D7.3020205@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org >> I suppose that begs the question of how NEA clients learn the profiles >> that they need to evaluate. > > I think it's "via the remediation network, which is outside of the > scope of NEA". not clear. at least the format of the profiles needs to be standardized, IMHO, otherwise there's no capability for interoperation and no point to having an NEA standard. >> Does the NEA protocol need to support, or >> is this somebody else's problem? What if the client connects and finds >> that its profile is out-of-date, should NEA allow the client to download >> the current profile? > > The server should decide if the clients profile is out of date. on that much we agree. the question is how the client gets the new profile. I don't like having the answer be "via the remediation network" because I think the whole concept of a remediation network is architecturally dubious. it might be fine for now but is not IMHO something we want to base a standard on. it also seems to me that some networks will not want to provide remediation but will want to use NEA and that NEA should still be able to provide a definite answer. that implies to me that the profile downloading should be able to happen via NEA, rather than introduce a situation where NEA can't tell whether a client is trustworthy or not because the client doesn't have a current profile. I also suspect that we're going to need to put some limitations on how frequently a profile can be changed in order to limit the potential for NEA to be used as a means of extracting arbitrary information from a client. If the server can keep changing the profile that's about as bad as allowing the server to iterate queries. > My take is that policy updates will happen much less often than > connection requests. So if nothing else, it's more efficient to not > have queries at every connection attempt. Since the queries and/or > policy updates may be large, it would be better to leverage real > networks for that process, rather than trying to carry large amounts of > data in the NEA protocol itself. what do you mean by "real networks"? do you assume that NEA will operate over something besides TCP/IP? TCP seems perfectly capable of carrying enough data to transmit an NEA profile. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 17:01:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwn1G-0008Or-5f; Tue, 19 Dec 2006 17:01:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwn1F-0008KD-80 for nea@ietf.org; Tue, 19 Dec 2006 17:01:05 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwn1B-0004lb-Q6 for nea@ietf.org; Tue, 19 Dec 2006 17:01:05 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 43DB5A70BA; Tue, 19 Dec 2006 14:00:51 -0800 (PST) Message-ID: <4588604D.7030101@deployingradius.com> Date: Tue, 19 Dec 2006 13:57:33 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Keith Moore Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> <458847C2.7060808@cs.utk.edu> In-Reply-To: <458847C2.7060808@cs.utk.edu> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Keith Moore wrote: > not clear. at least the format of the profiles needs to be > standardized, IMHO, otherwise there's no capability for interoperation > and no point to having an NEA standard. Yes. > ... that > implies to me that the profile downloading should be able to happen via > NEA, rather than introduce a situation where NEA can't tell whether a > client is trustworthy or not because the client doesn't have a current > profile. My main concern with this is that NEA is *before* the machine obtains full network access. So... how does it download potentially megabytes of updates? IP tunneling inside of NEA? Yuck... > what do you mean by "real networks"? do you assume that NEA will > operate over something besides TCP/IP? TCP seems perfectly capable of > carrying enough data to transmit an NEA profile. No, I mean TCP/IP shouldn't operate over NEA. That way lies madness. Remediation must use TCP/IP to download updates, but it can't use a public/open network (otherwise you wouldn't be using NEA). The remediation process therefore must severely limit the capability of the clients network connection. This can be done via a quarantine network as people do today. Or, it can be done via massive & dynamically updated filter rules, which are fragile and difficult to administer. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Dec 19 20:51:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwqc4-0005D2-Uy; Tue, 19 Dec 2006 20:51:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gwqc2-0005Ct-Vm for nea@ietf.org; Tue, 19 Dec 2006 20:51:18 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gwqc1-000864-Nu for nea@ietf.org; Tue, 19 Dec 2006 20:51:18 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 7E8675645A; Tue, 19 Dec 2006 20:51:09 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8YtDZ8ukzQf; Tue, 19 Dec 2006 20:51:02 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 400CF5643A; Tue, 19 Dec 2006 20:50:53 -0500 (EST) Message-ID: <458896FF.5010502@cs.utk.edu> Date: Tue, 19 Dec 2006 20:50:55 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Alan DeKok Subject: Re: Fwd: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> <458847C2.7060808@cs.utk.edu> <4588604D.7030101@deployingradius.com> In-Reply-To: <4588604D.7030101@deployingradius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org -------- Original Message -------- > Keith Moore wrote: >> not clear. at least the format of the profiles needs to be >> standardized, IMHO, otherwise there's no capability for interoperation >> and no point to having an NEA standard. > > Yes. > >> ... that >> implies to me that the profile downloading should be able to happen via >> NEA, rather than introduce a situation where NEA can't tell whether a >> client is trustworthy or not because the client doesn't have a current >> profile. > > My main concern with this is that NEA is *before* the machine obtains > full network access. So... how does it download potentially megabytes > of updates? IP tunneling inside of NEA? Yuck... I assume the network supports IP to the extent that it needs to implement NEA. It doesn't have to route IP packets anywhere other than between the host and the NEA server(s), but it does have to do that much. >> what do you mean by "real networks"? do you assume that NEA will >> operate over something besides TCP/IP? TCP seems perfectly capable of >> carrying enough data to transmit an NEA profile. > > No, I mean TCP/IP shouldn't operate over NEA. That way lies madness. perhaps, but nobody has suggested doing that. > Remediation must use TCP/IP to download updates, but it can't use a > public/open network (otherwise you wouldn't be using NEA). I'm not talking about remediation, I'm only talking about downloading the information that the NEA client needs to make the checks. This should be a list of generic tests, NOT arbitrary code. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 20 15:55:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx8Sy-0006I5-R8; Wed, 20 Dec 2006 15:55:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx8Sx-0006I0-Sz for nea@ietf.org; Wed, 20 Dec 2006 15:55:07 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx8Si-0002lw-77 for nea@ietf.org; Wed, 20 Dec 2006 15:55:07 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 20 Dec 2006 12:51:30 -0800 X-IronPort-AV: i="4.12,193,1165219200"; d="scan'208"; a="627953626:sNHT29797388" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Dec 2006 15:54:45 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA charter query Thread-index: Accghka7bxNoh2SnS0iCx3zty8l7DAACNLGAAAGffCAAjap7UAACEGIgAGY7qqA= From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Nea] NEA charter query X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Khaja Ahmed recently asked this question of the NEA chairs: > Given that we cannot discuss requirements that pertain to > internet wide usage, can we still discuss potential impact > of such a protocol if it were to be used in place it is not > designed for? ...i.e. the internet. The applicability limitation in our charter restricts our focus to "computing enterprise environments, 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." But this does not mean that the NEA protocols will only be carried over the enterprise network. Enterprises often use protocols over the Internet and it's not unlikely that NEA protocols might have to transit the Internet in a remote access scenario (with an appropriate PT). So we should expect the NEA protocols to be used on the Internet and include relevant requirements in our requirements document (security, congestion control, loss, wide variations in round trip time, etc.). But we should not cover non-enterprise use cases or situations where the endpoint is not owned by or expected to conform with the policies of the organization that owns and operates the network. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 20 16:41:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx9BO-0006XO-Qk; Wed, 20 Dec 2006 16:41:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx9BO-0006XJ-2e for nea@ietf.org; Wed, 20 Dec 2006 16:41:02 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx9BL-0002Pe-OO for nea@ietf.org; Wed, 20 Dec 2006 16:41:02 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id E917FA70BA; Wed, 20 Dec 2006 13:40:53 -0800 (PST) Message-ID: <4589AD22.5030200@deployingradius.com> Date: Wed, 20 Dec 2006 13:37:38 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] NEA charter query References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Stephen Hanna wrote: > ... Enterprises often > use protocols over the Internet and it's not unlikely that NEA > protocols might have to transit the Internet in a remote access > scenario (with an appropriate PT). I presume that the enterprise network isn't trusted, either. So NEA will have to include security such as SSL inside of the enterprise, too. Those security mechanisms can likely be leveraged to work for access from outside of the enterprise, too. > So we should expect the NEA protocols to be used on the Internet > and include relevant requirements in our requirements document > (security, congestion control, loss, wide variations in round > trip time, etc.). Once a security layer is defined to enable private transport of NEA information, the security transport protocol takes care of congestion control, loss, variations in round trip time, etc. The NEA requirements should include per-session timeouts on the client & server, but I don't see why packet congestion control is relevant. > But we should not cover non-enterprise use cases > or situations where the endpoint is not owned by or expected to > conform with the policies of the organization that owns and operates > the network. What about the case where the endpoint is not owned by the organization that operates the network, but is willing to conform with it's policies? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 20 17:34:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxA12-0007uL-QV; Wed, 20 Dec 2006 17:34:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxA12-0007qP-08 for nea@ietf.org; Wed, 20 Dec 2006 17:34:24 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxA10-0004Ag-Jb for nea@ietf.org; Wed, 20 Dec 2006 17:34:23 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBKMYFuZ011889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 20 Dec 2006 14:34:15 -0800 In-Reply-To: <458847C2.7060808@cs.utk.edu> References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> <458847C2.7060808@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <64DE0F22-BD54-4989-9129-16F84BB8C246@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) Date: Wed, 20 Dec 2006 14:34:14 -0800 To: Keith Moore X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org On Dec 19, 2006, at 12:12 PM, Keith Moore wrote: >>> I suppose that begs the question of how NEA clients learn the >>> profiles >>> that they need to evaluate. >> I think it's "via the remediation network, which is outside of the >> scope of NEA". > > not clear. at least the format of the profiles needs to be > standardized, IMHO, otherwise there's no capability for > interoperation and no point to having an NEA standard. It seems the entire exchange could be an exchanging certificates. The provider offers certificates in sets, perhaps by reference based upon a service URI, OS, and service name, where clients then request and verify a producer of the certificate which may be some third- party. Within the certificates held by the provider, there should be a time-stamp, their identity (perhaps hostmaster@), the type of service providing the certificate, suitable OS, and resources needed to obtain the service that in the end generates a certificate for the client based upon the client's identity. The black-box would be the service. The standardization would not need an elaborate profile, as this should be handled by the service as a means to retain privacy regarding the perhaps thousands of details involved. These certificates could be broken down into sets, such as OS patches, AV solutions, Network configuration, etc. The provider can decide what they find to be important by presenting both mandatory and option sets of certificates. The user could then be allowed to interact to select those certificates that pertain to their system, as well as which services they are willing to accept. The "profile" could be a simple status field entered into the certificate classifying a level of conformance achieved. There should be error codes to indicate which field has not been accepted, such as the time-stamp or the classification. Within the certificates, the status/classification result should provide adequate information upon which the provider could then make decisions on acceptance. >> The server should decide if the clients profile is out of date. > > on that much we agree. the question is how the client gets the new > profile. I don't like having the answer be "via the remediation > network" because I think the whole concept of a remediation network > is architecturally dubious. it might be fine for now but is not > IMHO something we want to base a standard on. it also seems to me > that some networks will not want to provide remediation but will > want to use NEA and that NEA should still be able to provide a > definite answer. that implies to me that the profile downloading > should be able to happen via NEA, rather than introduce a situation > where NEA can't tell whether a client is trustworthy or not because > the client doesn't have a current profile. > > I also suspect that we're going to need to put some limitations on > how frequently a profile can be changed in order to limit the > potential for NEA to be used as a means of extracting arbitrary > information from a client. If the server can keep changing the > profile that's about as bad as allowing the server to iterate queries. By indicating specifically what is required for a particular service, either the client or the provider could open their firewalls enough to allow these services to run. The protection is really found by knowing exactly what is needed. How the barriers are erected depends upon who feels threatened. Others sharing the network may wish to have the provider impose the barriers, but that is largely due to the current state. This state could be dramatically improved when using NEA to impose upon problematic clients a need to achieve compliance within a reasonable timeframe. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 20 18:24:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAnI-0007Vc-Cb; Wed, 20 Dec 2006 18:24:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxAnH-0007VX-8z for nea@ietf.org; Wed, 20 Dec 2006 18:24:15 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxAnF-0005Ub-3N for nea@ietf.org; Wed, 20 Dec 2006 18:24:15 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 40F7DA70BA; Wed, 20 Dec 2006 15:24:09 -0800 (PST) Message-ID: <4589C555.6050902@deployingradius.com> Date: Wed, 20 Dec 2006 15:20:53 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Douglas Otis Subject: Re: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> <458847C2.7060808@cs.utk.edu> <64DE0F22-BD54-4989-9129-16F84BB8C246@mail-abuse.org> In-Reply-To: <64DE0F22-BD54-4989-9129-16F84BB8C246@mail-abuse.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Douglas Otis wrote: > > It seems the entire exchange could be an exchanging certificates. The > provider offers certificates in sets, Why sets? Why not just one certificate? We can presume that NEA client policy updates are much rarer than network connection requests (i.e. posture assessments). In that case, the client can be issued a certificate for a particular network once it has downloaded the latest set of updates. That certificate may then be used for repeated posture assessments. i.e. the NEA server issues the client a certificate that validates a particular posture (or set of provider certificates). Once that's done, the client only has to present one certificate to the NEA server, rather than a set. When the NEA server decided that it has new updates available, it can compare the date of "last known update" to the "client certificate issue date". If the clients certificate was issued before the last update, then the client needs remediation. Otherwise, the client doesn't need remediation. The process then repeats. Similarly, if the client notices that updates are available, it can invalidate it's own certificate (i.e. by not using it), at which point the NEA server will ask it to perform remediation, and then issue a new certificate. > perhaps by reference based upon a > service URI, OS, and service name, where clients then request and verify > a producer of the certificate which may be some third-party. Within the > certificates held by the provider, there should be a time-stamp, their > identity (perhaps hostmaster@), the type of service providing the > certificate, suitable OS, and resources needed to obtain the service > that in the end generates a certificate for the client based upon the > client's identity. Yes, although it's not clear what provider posture information (if any) needs to be available to the NEA server. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Dec 20 19:36:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxBun-0001Es-Ct; Wed, 20 Dec 2006 19:36:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxBul-0001EW-PP for nea@ietf.org; Wed, 20 Dec 2006 19:36:03 -0500 Received: from wx-out-0506.google.com ([66.249.82.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxBuk-00068x-JK for nea@ietf.org; Wed, 20 Dec 2006 19:36:03 -0500 Received: by wx-out-0506.google.com with SMTP id h27so2239745wxd for ; Wed, 20 Dec 2006 16:36:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fy48cTa+93H+fQJ/1/f8RdcDYiKVrBq9oh8cbgxbfb0N7o97WiEYkIBSNv6yHzzgp0AmriCoNUJxjfsBZDggjgeiPKAbujeilRCPomBAaLBLefRVzQRtqsqW6bYbgIXqBW1Ae5E989ZRIw43guZKvgElADSswJt7NGsLsUksFMk= Received: by 10.70.129.4 with SMTP id b4mr13183060wxd.1166661362406; Wed, 20 Dec 2006 16:36:02 -0800 (PST) Received: by 10.65.158.12 with HTTP; Wed, 20 Dec 2006 16:35:32 -0800 (PST) Message-ID: Date: Wed, 20 Dec 2006 19:35:32 -0500 From: "Mike Fratto" To: "Alan DeKok" Subject: Re: [Nea] NEA charter query In-Reply-To: <4589AD22.5030200@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4589AD22.5030200@deployingradius.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org > > But we should not cover non-enterprise use cases > > or situations where the endpoint is not owned by or expected to > > conform with the policies of the organization that owns and operates > > the network. > > What about the case where the endpoint is not owned by the > organization that operates the network, but is willing to conform with > it's policies? That would be covered by "or expected to conform with the policies of the organization that owns and operates the network." _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Dec 21 10:36:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxPxy-0007Xx-Es; Thu, 21 Dec 2006 10:36:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxF62-0008I9-Uu for nea@ietf.org; Wed, 20 Dec 2006 22:59:54 -0500 Received: from bay0-omc1-s41.bay0.hotmail.com ([65.54.246.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxF60-0006ZM-LD for nea@ietf.org; Wed, 20 Dec 2006 22:59:54 -0500 Received: from hotmail.com ([207.46.8.100]) by bay0-omc1-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 20 Dec 2006 19:59:52 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 20 Dec 2006 19:59:51 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Thu, 21 Dec 2006 03:59:48 GMT X-Originating-IP: [71.37.34.63] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: nea@ietf.org Bcc: Date: Wed, 20 Dec 2006 19:59:48 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Dec 2006 03:59:51.0850 (UTC) FILETIME=[775AC8A0:01C724B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Thu, 21 Dec 2006 10:36:17 -0500 Subject: [Nea] Re: NEA network location? X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Steve Hanna said: "So we should expect the NEA protocols to be used on the Internet and include relevant requirements in our requirements document (security, congestion control, loss, wide variations in round trip time, etc.). But we should not cover non-enterprise use cases or situations where the endpoint is not owned by or expected to conform with the policies of the organization that owns and operates the network." Of course, this begs the question of how NEA behavior can differ in the enterprise and Internet cases. From an authentication perspective, EAP is run between the peer to the server, and so the intervening network(s) simply don't come into play. So if you examine packet traces for the "enterprise" and the "Internet" cases, there will be no discernible difference between them, as long as the peer and server are the same. Of course, your mileage will vary for other "transports", which may not have the same "end to end" properties as EAP. However, in those cases, there are some very fundamental issues with mobility support. And of course, one of the issues motivating NEA is mobility; if we are talking only about desktops sitting in one place, with permanent connectivity, why can't existing software update solutions do the job? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Dec 21 11:25:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQj9-0001he-2z; Thu, 21 Dec 2006 11:25:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxQj6-0001gy-Vi for nea@ietf.org; Thu, 21 Dec 2006 11:25:00 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxQgj-0006r3-Aw for nea@ietf.org; Thu, 21 Dec 2006 11:22:35 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 21 Dec 2006 08:19:11 -0800 X-IronPort-AV: i="4.12,199,1165219200"; d="scan'208"; a="642530126:sNHT52198700" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] Re: NEA network location? Date: Thu, 21 Dec 2006 11:22:31 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Re: NEA network location? Thread-index: AcclFdPJU7AZbUVcTqKw+Ko9J3YpUwAAb9nQ From: "Stephen Hanna" To: "Bernard Aboba" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I did not mean to suggest that the requirements for running NEA protocols over the Internet are substantially different from running them over an enterprise network. In many cases (maybe most or all cases), they will not differ. I was simply answering a question about whether we can ignore requirements derived from running the NEA protocols over the Internet. We cannot. Thanks, Steve -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Wednesday, December 20, 2006 11:00 PM To: nea@ietf.org Subject: [Nea] Re: NEA network location? Steve Hanna said: "So we should expect the NEA protocols to be used on the Internet and include relevant requirements in our requirements document (security, congestion control, loss, wide variations in round trip time, etc.). But we should not cover non-enterprise use cases or situations where the endpoint is not owned by or expected to conform with the policies of the organization that owns and operates the network." Of course, this begs the question of how NEA behavior can differ in the=20 enterprise and Internet cases. From an authentication perspective, EAP is=20 run between the peer to the server, and so the intervening network(s) simply=20 don't come into play. So if you examine packet traces for the "enterprise"=20 and the "Internet" cases, there will be no discernible difference between=20 them, as long as the peer and server are the same. Of course, your mileage will vary for other "transports", which may not have=20 the same "end to end" properties as EAP. However, in those cases, there are=20 some very fundamental issues with mobility support. And of course, one of=20 the issues motivating NEA is mobility; if we are talking only about=20 desktops sitting in one place, with permanent connectivity, why can't=20 existing software update solutions do the job? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Dec 21 14:39:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTlb-0006Fj-9H; Thu, 21 Dec 2006 14:39:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxTla-0006Fe-PP for nea@ietf.org; Thu, 21 Dec 2006 14:39:46 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxTlY-00030F-80 for nea@ietf.org; Thu, 21 Dec 2006 14:39:46 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBLJdZVN000633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Dec 2006 11:39:35 -0800 In-Reply-To: <4589C555.6050902@deployingradius.com> References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> <458847C2.7060808@cs.utk.edu> <64DE0F22-BD54-4989-9129-16F84BB8C246@mail-abuse.org> <4589C555.6050902@deployingradius.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) Date: Thu, 21 Dec 2006 11:39:33 -0800 To: Alan DeKok X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org On Dec 20, 2006, at 3:20 PM, Alan DeKok wrote: > Douglas Otis wrote: >> >> It seems the entire exchange could be an exchanging certificates. >> The provider offers certificates in sets, > > Why sets? Why not just one certificate? Assume services might be offered by various third-parties. There is a likelihood a service might work for one OS and not another. By indicating the type of service and the suitable OS within each certificate, the user could then select a service that is both compatible and acceptable. There could be mandatory sets, and optional sets. In the case of optional sets, these could be seen as advertisements of recommended services. Even within an enterprise environment, it is extremely common for laptops from individuals outside the enterprise to seek access. It should not be assumed that everyone uses Windows or MacOSX. Linux and FreeBSD are also fairly common, depending upon the nature of the work. Within the IETF, this list will be even larger. It seems eating one's own dog food provides a good basis for judging requirements. Can IETF meetings utilize NEA? > We can presume that NEA client policy updates are much rarer than > network connection requests (i.e. posture assessments). In that > case, the client can be issued a certificate for a particular > network once it has downloaded the latest set of updates. That > certificate may then be used for repeated posture assessments. Who is producing the certificate? Who is offering the service? You do not want individuals to start trusting just any access point running NEA. Service providers should be the ones offering the certificates. Each service may need to update on a regular basis. Each service may represent a large diversity of service providers. > i.e. the NEA server issues the client a certificate that validates > a particular posture (or set of provider certificates). Once > that's done, the client only has to present one certificate to the > NEA server, rather than a set. It seems impractical for an NEA server to assess thousands of details related to various services being contemplated. Unless the certificate is something as simple as agreeing to an AUP, the NEA server is not really able to generate certificates directly. The NEA server must delegate assessments to trusted organizations able to properly determine the state of the client. The NEA server does not need to know these details, nor is that really desired. The NEA server indicates which services they both trust and expect to have been completed by the client. The NEA server may also recommend services as well. > When the NEA server decided that it has new updates available, it > can compare the date of "last known update" to the "client > certificate issue date". If the clients certificate was issued > before the last update, then the client needs remediation. > Otherwise, the client doesn't need remediation. The process then > repeats. The NEA server might know that service X has a critical update available at time Y. The NEA server could then reject certificates that might make the client prone to a zero-day exploit. Being able to tell the client to open specific resources and obtain a specific service would be one method that NEA might help prevent non- compromised systems from being compromised. Certificates should be consider simply an end-product of completing some service. There might be many services needed to support a possibly vast array of systems and uses, even within an enterprise environment. The NEA would list these Certificates by reference and allow the client to request the host's version of the certificate when needed. (This would be a rare event.) > Similarly, if the client notices that updates are available, it can > invalidate it's own certificate (i.e. by not using it), at which > point the NEA server will ask it to perform remediation, and then > issue a new certificate. I don't see that as part of the NEA service. Most of these types of services are already done routinely. There might be cases where this routine needs to be changed in the face of a new zero-day exploit. It can also help large organizations better track problematic systems. There have been embarrassing situations where some system within an enterprise becomes compromised, and this machine must be physically found to correct the situation. Knowing the nature of the problem might allow targeted services aimed at resolving specific issues. They happen far too often to not be considered. >> perhaps by reference based upon a service URI, OS, and service >> name, where clients then request and verify a producer of the >> certificate which may be some third-party. Within the >> certificates held by the provider, there should be a time-stamp, >> their identity (perhaps hostmaster@), the type of service >> providing the certificate, suitable OS, and resources needed to >> obtain the service that in the end generates a certificate for the >> client based upon the client's identity. > > Yes, although it's not clear what provider posture information (if > any) needs to be available to the NEA server. The posture information would be in the form of a service completion classification. This completion classification might be "Server-OS updated". The information conveyed could be extremely general, and yet offer all that is needed when deciding acceptance. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Dec 21 16:19:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxVJW-0000u8-S8; Thu, 21 Dec 2006 16:18:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxVJW-0000tn-5x for nea@ietf.org; Thu, 21 Dec 2006 16:18:54 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxVJU-0006Ax-Lb for nea@ietf.org; Thu, 21 Dec 2006 16:18:54 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 4B733A70BA; Thu, 21 Dec 2006 13:18:49 -0800 (PST) Message-ID: <458AF973.3030108@deployingradius.com> Date: Thu, 21 Dec 2006 13:15:31 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Douglas Otis Subject: Re: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> <458847C2.7060808@cs.utk.edu> <64DE0F22-BD54-4989-9129-16F84BB8C246@mail-abuse.org> <4589C555.6050902@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Douglas Otis wrote: > Assume services might be offered by various third-parties. There is a > likelihood a service might work for one OS and not another. By > indicating the type of service and the suitable OS within each > certificate, the user could then select a service that is both > compatible and acceptable. Yes... each third party (virus scanner, etc.) would indicate the scenarios under which it's validation of the clients posture is OK. But as I stated earlier, there's no need to exchange the full set of certificates for every network access request. > Who is producing the certificate? Who is offering the service? You do > not want individuals to start trusting just any access point running > NEA. The charter scenario targets the enterprise space, where NEA client and server are in the same administrative domain (i.e. owned by the same people). In that case, trust is irrelevant, because there's only one party involved: the enterprise that owns the equipment. And the enterprise administrators are the ones producing the certificates and offering the services. For the case of someone visiting an enterprise with NEA, they can choose to trust the NEA server and accept it's security policies. Or, they can choose to not trust it, and then not obtain network access. > Service providers should be the ones offering the certificates. The service provider space is explicitly outside of the WG charter. Maybe you mean "services offered by third parties", as above? Overloading the word "service" here is impractical. And your discussion mixes "service" as third party software running on both the client and server, *and* as the action of doing something to obtain updates. As a result, it's extremely difficult to understand what you're getting at. > It seems impractical for an NEA server to assess thousands of details > related to various services being contemplated. Then NEA as a whole is impractical. > Unless the certificate > is something as simple as agreeing to an AUP, the NEA server is not > really able to generate certificates directly. I fail to understand why. If others can produce certificates, then the NEA server can produce them, too. If others can supply their certificates (i.e. posture assessment) to the NEA server, then it can produce a certificate saying that it believes the client is compliant at a particular date. And the only certificate that normally needs to be presented to the NEA server is the one issued by the NEA server. > The NEA server might know that service X has a critical update available > at time Y. The NEA server could then reject certificates that might > make the client prone to a zero-day exploit. Which is a scenario I explicitly described, and which my proposal was demonstrated to satisfy. I don't think you're disagreeing with me, but you don't seem to be addressing my proposal. > The posture information would be in the form of a service completion > classification. This completion classification might be "Server-OS > updated". The information conveyed could be extremely general, and yet > offer all that is needed when deciding acceptance. I have no idea what that means. I haven't seem that terminology explained, or used elsewhere, so it is difficult for to establish a frame of reference. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Dec 21 21:32:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxaCw-00060t-Ve; Thu, 21 Dec 2006 21:32:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxaCw-0005zT-3v for nea@ietf.org; Thu, 21 Dec 2006 21:32:26 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxaCu-0000O2-HS for nea@ietf.org; Thu, 21 Dec 2006 21:32:26 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBM2WIQi007494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Dec 2006 18:32:19 -0800 In-Reply-To: <458AF973.3030108@deployingradius.com> References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> <458847C2.7060808@cs.utk.edu> <64DE0F22-BD54-4989-9129-16F84BB8C246@mail-abuse.org> <4589C555.6050902@deployingradius.com> <458AF973.3030108@deployingradius.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <81549132-74A0-4A5D-B46D-A0DB10F2190D@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) Date: Thu, 21 Dec 2006 18:32:17 -0800 To: Alan DeKok X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org On Dec 21, 2006, at 1:15 PM, Alan DeKok wrote: > Douglas Otis wrote: >> Assume services might be offered by various third-parties. There >> is a likelihood a service might work for one OS and not another. >> By indicating the type of service and the suitable OS within each >> certificate, the user could then select a service that is both >> compatible and acceptable. > > Yes... each third party (virus scanner, etc.) would indicate the > scenarios under which it's validation of the clients posture is > OK. But as I stated earlier, there's no need to exchange the full > set of certificates for every network access request. The goal is to minimize data held within a certificate such that it remains possible to hold several within a single packet. When the number of certificates becomes burdensome, an exchange reduction could be accomplished by a "caching" NEA server producing a certificate that reflects the client's certificates currently held. That seems overly complex for what is likely not a problem when certificates are kept to a minimum size. >> Who is producing the certificate? Who is offering the service? >> You do not want individuals to start trusting just any access >> point running NEA. > > The charter scenario targets the enterprise space, where NEA > client and server are in the same administrative domain (i.e. owned > by the same people). In that case, trust is irrelevant, because > there's only one party involved: the enterprise that owns the > equipment. And the enterprise administrators are the ones > producing the certificates and offering the services. Any large enterprise will host a number of guests, contractors, salesmen, and consultants. These individuals should not be forced to trust some NEA server's profiling application. Few will remain within the same environment, so NEA should consider the effects a compromised NEA server might have. The NEA design should allow the entities providing services be trusted instead, rather than a larger number of NEA servers of questionable status. Rather than assuming a work environment requires that one must always expose their system directly to the NEA server, a normal mode of operation should permit trust based upon those directly providing a service, such as OS updates or AV scanners. Few would want to be forced to run an enterprise Brand X application that does who-knows-what at an administrative level. Working within an enterprise environment should not demand the NEA server itself be trusted. > For the case of someone visiting an enterprise with NEA, they can > choose to trust the NEA server and accept it's security policies. > Or, they can choose to not trust it, and then not obtain network > access. > >> Service providers should be the ones offering the certificates. > > The service provider space is explicitly outside of the WG charter. > > Maybe you mean "services offered by third parties", as above? The word service might cover any number of things related to securing the client. OS, applications, as well as supplemental defenses-in- depth could be covered by the term service. By service provider, this was not meant to imply an access server provider, although they would not be excluded either. > Overloading the word "service" here is impractical. And your > discussion mixes "service" as third party software running on both > the client and server, *and* as the action of doing something to > obtain updates. As a result, it's extremely difficult to > understand what you're getting at. What would you suggest that it be called? How about Comprehensive Assessment and Remediation (CAR) service? >> It seems impractical for an NEA server to assess thousands of >> details related to various services being contemplated. > > Then NEA as a whole is impractical. NEA facilitates a means to communicate with an endpoint specific requirements based upon generalized status contained within a CAR certificate. The CAR service is well beyond the scope of the NEA server. CAR certificates form a basis for NEA acceptance or notification. The NEA server should not be directly trusted in providing CAR services however. >> Unless the certificate is something as simple as agreeing to an >> AUP, the NEA server is not really able to generate certificates >> directly. > > I fail to understand why. If others can produce certificates, > then the NEA server can produce them, too. If others can supply > their certificates (i.e. posture assessment) to the NEA server, > then it can produce a certificate saying that it believes the > client is compliant at a particular date. And the only certificate > that normally needs to be presented to the NEA server is the one > issued by the NEA server. An NEA server could offer minimally intrusive CAR services, such as negotiating an AUP or caching previously exchanged certificates. It seems a bad idea to add more points of trust at administrative levels and pose the potential for catastrophic security breaches. Leveraging existing trusted services would be much safer, more acceptable, and easier to administer. >> The NEA server might know that service X has a critical update >> available at time Y. The NEA server could then reject >> certificates that might make the client prone to a zero-day exploit. > > Which is a scenario I explicitly described, and which my proposal > was demonstrated to satisfy. I don't think you're disagreeing with > me, but you don't seem to be addressing my proposal. Ensure there is a two-way negotiation of CAR services. The NEA server should in essence say "pick one from each set" and then offer a related certificate. For details, the Server can offer their certificate signed for them (i.e. hostmaster@). These sets might be mandatory or simply recommended. >> The posture information would be in the form of a service >> completion classification. This completion classification might >> be "Server-OS updated". The information conveyed could be >> extremely general, and yet offer all that is needed when deciding >> acceptance. > > I have no idea what that means. I haven't seem that terminology > explained, or used elsewhere, so it is difficult for to establish a > frame of reference. Provide a clearer distinction between what a CAR provides and what an NEA server negotiates. In essence, NEA adds a requirement that CAR services offer clients a receipt in the form of a certificate. These services exist today. With a minimal effort, these certificates can be exchanged indicating the results. The NEA server is not where these CAR services are run without major and rather risky changes. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Dec 22 02:25:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxemf-0006Il-8c; Fri, 22 Dec 2006 02:25:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxeme-0006Ig-If for nea@ietf.org; Fri, 22 Dec 2006 02:25:36 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxemZ-0006sd-3P for nea@ietf.org; Fri, 22 Dec 2006 02:25:36 -0500 Received: from [192.168.1.100] (adsl-75-10-243-139.dsl.pltn13.sbcglobal.net [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 0C444A70BA; Thu, 21 Dec 2006 23:25:25 -0800 (PST) Message-ID: <458B87A2.9020109@deployingradius.com> Date: Thu, 21 Dec 2006 23:22:10 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Douglas Otis Subject: Re: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> <458847C2.7060808@cs.utk.edu> <64DE0F22-BD54-4989-9129-16F84BB8C246@mail-abuse.org> <4589C555.6050902@deployingradius.com> <458AF973.3030108@deployingradius.com> <81549132-74A0-4A5D-B46D-A0DB10F2190D@mail-abuse.org> In-Reply-To: <81549132-74A0-4A5D-B46D-A0DB10F2190D@mail-abuse.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Douglas Otis wrote: > The goal is to minimize data held within a certificate such that it > remains possible to hold several within a single packet. I can't find that goal in the charter text. If it is a goal, it's secondary to the goals stated in the charter. > When the > number of certificates becomes burdensome, an exchange reduction could > be accomplished by a "caching" NEA server producing a certificate that > reflects the client's certificates currently held. That seems overly > complex for what is likely not a problem when certificates are kept to a > minimum size. Why not have one solution that works everywhere, for all cases? > The word service might cover any number of things related to securing > the client. OS, applications, as well as supplemental defenses-in-depth > could be covered by the term service. A word that can take on any meaning ends up meaning nothing. > What would you suggest that it be called? How about Comprehensive > Assessment and Remediation (CAR) service? How about using the terms from the charter? > It > seems a bad idea to add more points of trust at administrative levels > and pose the potential for catastrophic security breaches. Leveraging > existing trusted services would be much safer, more acceptable, and > easier to administer. There are no trust issues in an NEA client accepting a certificate from an NEA server. That certificate says *nothing* to the client. It's just a magic token that the client needs to use to obtain access in a particular enterpise network. The certificate has meaning to the NEA server that issued it. The NEA server "trusts" the certificate... because it issued the certificate. As for clients not holding a valid certificate, a contractors NEA client is perfectly free to *not* trust the NEA server for a particular enterprise. In that case, please explain why the NEA server would trust the client, and let that client on it's network. The answer is "it won't". Your whole worry about trust is misplaced, and is causing you to come up with convoluted scenarios and solutions. Allowing a client to obtain network access if it passes posture assessment by third parties is ridiculous: they don't own the network. The enterprise administrator running the NEA server owns the network, and is the ONLY one who controls network access. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Dec 22 11:23:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxnBV-0003gZ-Ne; Fri, 22 Dec 2006 11:23:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxnBU-0003ed-1j for nea@ietf.org; Fri, 22 Dec 2006 11:23:48 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxnBS-00049U-Ib for nea@ietf.org; Fri, 22 Dec 2006 11:23:48 -0500 Received: from [192.168.2.47] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBMGNeG9016214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Dec 2006 08:23:40 -0800 In-Reply-To: <458B87A2.9020109@deployingradius.com> References: <4580993D.1070405@deployingradius.com> <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> <458847C2.7060808@cs.utk.edu> <64DE0F22-BD54-4989-9129-16F84BB8C246@mail-abuse.org> <4589C555.6050902@deployingradius.com> <458AF973.3030108@deployingradius.com> <81549132-74A0-4A5D-B46D-A0DB10F2190D@mail-abus! e .org> <458B87A2.9020109@deployingradius.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) Date: Fri, 22 Dec 2006 08:23:38 -0800 To: Alan DeKok X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org On Dec 21, 2006, at 11:22 PM, Alan DeKok wrote: > Douglas Otis wrote: >> The goal is to minimize data held within a certificate such that >> it remains possible to hold several within a single packet. > > I can't find that goal in the charter text. If it is a goal, > it's secondary to the goals stated in the charter. Sending posture data (describing the state of third-party software) seems unlikely to result in either standardization or minimized amounts of data. 1) The signing of the collected information should not occur at the client. 2) The signing of the collected information should not occur within the NEA architecture. Consider how this task is best described, and used to both standardize and minimize the information being exchanged. >> When the number of certificates becomes burdensome, an exchange >> reduction could be accomplished by a "caching" NEA server >> producing a certificate that reflects the client's certificates >> currently held. That seems overly complex for what is likely not >> a problem when certificates are kept to a minimum size. > > Why not have one solution that works everywhere, for all cases? That was being suggested. Allow an exchange by reference, and allow specific "Host" certificates (those signed with hostmaster@ for example) to be requested in order to determine the validity of the service and the related resource information based upon mutually trusted third-parties. You seem to be suggesting that a component of the NEA will be creating and vouching for this information. That would reduce the general level of security. >> What would you suggest that it be called? How about Comprehensive >> Assessment and Remediation (CAR) service? > > How about using the terms from the charter? The charter does not fully describe this function and only refers to this as Posture information. The reason for introducing this terminology is to suggest that NEA should not be the entity trusted to provide Posture information except perhaps in non-intrusive cases. Stating that the environment is "Enterprise" does not justify getting sloppy about points of trust. >> It seems a bad idea to add more points of trust at administrative >> levels and pose the potential for catastrophic security breaches. >> Leveraging existing trusted services would be much safer, more >> acceptable, and easier to administer. > > There are no trust issues in an NEA client accepting a certificate > from an NEA server. That certificate says *nothing* to the > client. It's just a magic token that the client needs to use to > obtain access in a particular enterprise network. The certificate must be trusted by the client before acting upon the information contained. This might involve firewall settings and where Posturing related services might be obtained, for example. It would be a bad practice to assume that within an "Enterprise" environment, the NEA server _must_ be considered trustworthy. When coming into an environment, what standards would allow guests to safely accept information and services being offered? This trust is best established directly from organizations offering services that can _actually_ establish Posture information. This would greatly improve the chances that employee X from company Y can accept NEA requests made by company Z. > The certificate has meaning to the NEA server that issued it. The > NEA server "trusts" the certificate... because it issued the > certificate. That is not in question. > As for clients not holding a valid certificate, a contractors NEA > client is perfectly free to *not* trust the NEA server for a > particular enterprise. In that case, please explain why the NEA > server would trust the client, and let that client on it's network. There would be CAR service providers mutually trusted by both the client and the NEA server. In "guest hostile" environments, there might be requirements to accept services being offered or by the NEA server or else not gain acceptance. This is very poor solution that will likely decrease network security by forcing trust in this manner. > The answer is "it won't". Your whole worry about trust is > misplaced, and is causing you to come up with convoluted scenarios > and solutions. The CAR related services, for the most part, already exist in various forms within various OS environments. It is unlikely that thousands of organizations will wish to "reinvent" the detailed and complex efforts required to establish useful Posture information. By looking to what already exists, introduction of NEA is less likely to introduce unacceptable trust requirements of perhaps questionably maintained NEA servers. > Allowing a client to obtain network access if it passes posture > assessment by third parties is ridiculous: they don't own the > network. The enterprise administrator running the NEA server owns > the network, and is the ONLY one who controls network access. A mutually trusted service is not ridiculous. Expecting various enterprises to create their own "CAR service wrapper" to produce posture certificates represents a poor choice with respect to security. When NEA gets accepted, third-party CAR service providers will be willing to directly offer NEA compatible certificates. This would improve the odds that a technician or sale rep would be able to utilize a network without introducing an array of questionable applications into their system. A reasonable list of certificates recognized by NEA servers will accommodate a fairly large population without forcing someone to blindly trust some application. In general, a requirement of blind trust is a bad idea, especially within an enterprise environment. Imagine the precedent this would be setting. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Dec 22 12:01:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxnm4-0004xv-G1; Fri, 22 Dec 2006 12:01:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gxnm3-0004xp-At for nea@ietf.org; Fri, 22 Dec 2006 12:01:35 -0500 Received: from adsl-75-10-243-137.dsl.pltn13.sbcglobal.net ([75.10.243.137] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gxnly-0002BA-Rx for nea@ietf.org; Fri, 22 Dec 2006 12:01:35 -0500 Received: from [192.168.1.100] (unknown [75.10.243.139]) by book.deployingradius.com (Postfix) with ESMTP id 8371BA70BA; Fri, 22 Dec 2006 09:01:28 -0800 (PST) Message-ID: <458C0E8D.40901@deployingradius.com> Date: Fri, 22 Dec 2006 08:57:49 -0800 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Douglas Otis Subject: Re: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) References: <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> <458847C2.7060808@cs.utk.edu> <64DE0F22-BD54-4989-9129-16F84BB8C246@mail-abuse.org> <4589C555.6050902@deployingradius.com> <458AF973.3030108@deployingradius.com> <81549132-74A0-4A5D-B46D-A0DB10F2190D@mail-abus! e .org> <458B87A2.9020109@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Douglas Otis wrote: > That was being suggested. Allow an exchange by reference, and allow > specific "Host" certificates (those signed with hostmaster@ for example) > to be requested in order to determine the validity of the service and > the related resource information based upon mutually trusted > third-parties. That isn't in dispute. > You seem to be suggesting that a component of the NEA > will be creating and vouching for this information. That would reduce > the general level of security. No, I did NOT say that. Please read my messages again. >> Allowing a client to obtain network access if it passes posture >> assessment by third parties is ridiculous: they don't own the network. >> The enterprise administrator running the NEA server owns the network, >> and is the ONLY one who controls network access. > > A mutually trusted service is not ridiculous. Did you read the text you're allegedly responding to? I won't respond to the rest of your post. It's yet another repetition of the same opinions, and doesn't address my earlier comments about those opinions. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Dec 22 14:34:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxqAJ-00049k-Tq; Fri, 22 Dec 2006 14:34:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GxqAI-00049e-F2 for nea@ietf.org; Fri, 22 Dec 2006 14:34:46 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GxqAG-00013w-47 for nea@ietf.org; Fri, 22 Dec 2006 14:34:46 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kBMJYe0P026279 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Dec 2006 11:34:40 -0800 In-Reply-To: <458C0E8D.40901@deployingradius.com> References: <4580A0C4.2000605@cs.utk.edu> <4586D002.3050800@deployingradius.com> <4586F499.10101@deployingradius.com> <4587F272.8020701@cs.utk.edu> <45882DDB.6060901@deployingradius.com> <4588350B.9030008@cs.utk.edu> <458843D7.3020205@deployingradius.com> <458847C2.7060808@cs.utk.edu> <64DE0F22-BD54-4989-9129-16F84BB8C246@mail-abuse.org> <4589C555.6050902@deployingradius.com> <458AF973.3030108@deployingradius.com> <81549132-74A0-4A5D-B46D-A0DB10F2190D@mail-abus! e .org> <458B87A2.9020109@deployingradius.com> <458C0E8D.40901@deployingradius.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <54B481DA-A370-4BBF-A65C-836DE2FBF1EE@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: NEA requirements (was Re: Fwd: [Nea] Re: use of a design team to develop requirements) Date: Fri, 22 Dec 2006 11:34:39 -0800 To: Alan DeKok X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: nea@ietf.org, Keith Moore X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org On Dec 22, 2006, at 8:57 AM, Alan DeKok wrote: > Douglas Otis wrote: >> >> A mutually trusted service is not ridiculous. > > Did you read the text you're allegedly responding to? Review the open issues for discussion indicated in the charter. If you have an I-D you would like reviewed, please provide a reference. Sharing elaborate system details with every NEA server is not a good strategy for security or compatibility. It is difficult to imagine that asking the end-point what they claim to have accomplished offers any type of solution whatsoever. Such a solution will be immediately defeated. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea