Network Endpoint Assessment (NEA) BOF Draft Agenda Agenda Bashing (5 minutes) NEA Problem Statement (45 minutes) Proposed NEA Charter (45 minutes) Consensus Check and Volunteering (25 minutes) The goal of the NEA BOF is to confirm rough consensus on the NEA problem statement, on the importance of forming an IETF Working Group to address the problems described in that document, and on the proposed charter for such a Working Group. Further, the NEA BOF will verify that there are enough participants to make the NEA effort a success. NEA BOF participants are expected to have read the documents listed below before the BOF meeting. Discussion of these documents before the BOF meeting is strongly encouraged. It will take place on the nea@ietf.org mailing list. Proposed NEA WG Charter Network Endpoint Assessment (NEA) Problem Statement draft-thomson-nea-problem-statement-01.txt Mailing List nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea -------- Proposed NEA WG Charter Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy for access to the network. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. On network access, an endpoint with an NEA Client can be queried for posture information which is validated on an NEA Server as part of network access control. While several of these architectures leverage the EAP/RADIUS framework so that both authentication and posture assessment can be part of network access control, components from the different architectures do not interoperate because not all of the required protocols are standards. The first purpose of the proposed working group is to define requirements for those protocols needed to ensure interoperability. The second purpose of the working group is to determine whether existing protocols are sufficient to meet these requirements and, when not, to ensure standardization of protocols or protocol extensions which meet the requirements. In some cases, these protocols or protocol extensions may best be standardized in another working group. Therefore, the proposed working group will work with the area directors to determine the best way to complete this standardization effort (in the proposed working group or in another one). The initial scope of the WG targets an NEA architecture based on the EAP/RADIUS framework. Other instantiations of NEA architectures may be standardized in the future, but are not part of the initial charter. The initial charter includes defining requirements for the following protocols: 1. Posture Broker (PB) protocol: This protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. 2. Posture Transport Tunnel (PTT) protocol: In the EAP framework, this is an EAP tunneling method suitable for tunneling the PB protocol as well as supporting authentication. 3. Posture Transport Carrier (PTC) protocol: The EAP framework supports running EAP over multiple carriers. Targeted deployment scenarios for NEA include both L2 and L3 network access scenarios. Existing standards used in NEA include 802.1x for L2 network access. Requirements need to be defined for an EAP over L3 transport for L3 access scenarios. 4. Network access enforcement (NAE) protocol: In an EAP/RADIUS framework, RADIUS is the protocol used between a network enforcement point and an NEA server acting as an authentication and posture validation server. Requirements may identify new attributes needed (if any). Other protocols that may be included in the charter at a later date include: 5. Posture Attribute (PA) protocol: This protocol is used to carry posture attributes between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. 6. Posture Validation Protocol (PV): The NEA Server may have a distributed implementation such that the Posture Validator is a remote component. The PV protocol forwards posture attributes to a remote Posture Validator and receives the result of the assessment. Work will be carried out in two phases. In the first phase, the WG will define requirements for each of the protocols identified in 1) - 4) above. When the requirements have been defined, this WG will work with the responsible Area Directors to identify the appropriate WG for meeting these requirements. Milestones: June 2006: * Submit requirements I-D to IETF including --- requirements for PTT protocol (EAP tunneling method) --- requirements for NAE protocol (RADIUS extensions) September 2006: * Submit revised requirements I-D to IETF that includes above plus: --- requirements for PB protocol --- requirements for PTC (EAP over IP carrier protocol) December 2006: * Review ongoing work in IETF (e.g. EMU WG, Radext WG, PANA WG, NEA WG) and work with ADs to identify the WG responsible for accommodating protocol requirements that are not currently being met. Feb 2007: * Submit requirements I-D to IESG for publication as Info RFC * Revise WG charter to accommodate definition of protocols not covered in other WGs e.g. PB * Submit I-D on protocols to be defined in this WG e.g. PB specification