 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
I think we need to bound the scope of
interoperability, or we’ll give ourselves an impossible problem to solve.
Trying to get “industry-standard semantically-rich” posture
reports feels like an unachievable goal. Trying to get an NEA agent broker from
one vendor and an NEA server broker from another vendor to successfully exchange
reports seems a more achievable goal. I’d like us to first focus on the
transport mechanism between the agent and the server, and if we have success in
standardizing that, then we can move on to standardizing some forms of posture
reports. Barbara. From:
nea-bounces at ietf.org [mailto:nea-bounces at ietf.org] On Behalf Of Thomas Hardjono The Charter
looks great. One nit: if
interoperability is the target, perhaps one of the items that maybe useful is a
standard structure for the posture information being sent from the NEA-Agent to
the NEA-Server. Thus, not only
should NEA define the *type* of pipe (the "how") that extends
between the NEA-Plugin and NEA-Posture-Server, but also *what* kinds of
meaningful stuff flows between the two end-points. This would allow
true cross-vendor interoperability of NEA-Agents and NEA-Servers products
(from differing H/W vendors and S/W ISVs). Looking at the
proposed charter, the EAP-Method in IF-PT could include this work item.
However, usually when the EAP WG talks about EAP-methods it doesn't
specifically include semantically-rich posture reports. Does this make
sense? cheers, /thomas/ From:
nea-bounces at ietf.org [mailto:nea-bounces at ietf.org] On Behalf Of Susan Thomson (sethomso) Architectures have been implemented in the industry to
assess the software or hardware configuration of endpoint devices for
the purposes of monitoring or enforcing compliance of endpoints to an
organization's policy for access to the network. These architectures are
not fully interoperable since some of the protocols used to implement the
architecture are not standards. The first purpose of the proposed working group is to define
requirements for the protocols needed to ensure interoperability in an NEA
system. The second purpose of the working group is to ensure standardization of
protocols that meet these requirements. In some cases, these protocols 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 scope of the initial charter is on the following
protocols that support architectures for network endpoint assessment (as
described in draft-thomson-nea-problem-statement-00.txt): 1. IF-PB (posture broker protocol) 2. IF-PT (EAP method suitable for carrying posture
information as well as supporting authentication) 3. IF-PT (EAP over IP transport protocol) 4. IF-NAE (Radius attributes for network access enforcement) Other interfaces that may be included in the charter
at a later date include: --- IF-PA (posture attribute protocol) --- IF-SB (Protocol between server broker and posture
server. Name of interface TBD in problem-statement I-D. ) Note that the initial scope of the WG targets architectures
that use the EAP/Radius framework for IF-PT (posture transport interface) and
IF-NAE (network access enforcement interface). This does not preclude the
standardization of other posture transport protocols or network
authorization protocols in the future, but this is not part of the initial
charter. 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 ADs to identify the
appropriate WG for meeting these requirements. Milestones: June 2006: * Submit requirements I-D to IETF including --- requirements for IF-PT (EAP method layer) --- requirements for IF-NAE September 2006: * Submit revised requirements I-D to IETF that includes
above plus: --- requirements for IF -PT (EAP over IP
transport layer e.g. EAP over UDP, EAP over TLS) --- requirements for IF-PB 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. IF-PB * Submit I-D on protocols to be defined in this
WG e.g. IF-PB specification |
_______________________________________________ Nea mailing list Nea at ietf.org https://www1.ietf.org/mailman/listinfo/nea