[Nea] Revised charter (again)

["Susan Thomson \(sethomso\)" <sethomso at cisco.com>]

Below is another version of the charter for your review.

Based on a discussion with the Internet ADs last week, we realized that
the charter depended too heavily on information in the problem statement
I-D. To enable the charter to stand on its own, it has been updated to
include more detail on the problem being addressed and provides a 1 or
2-sentence description with each of the protocols. Also, protocol names
no longer have the "IF-" prefix.

The scope and milestones remain unchanged.

Please provide comments before the end of the week, so that it can be
updated prior to BoF.

Thanks
Steve & Susan

-----------------------------------------------
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

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea