 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Sure, I think that's a reasonable timeline/phases to
follow. Working on a standard transport mechanism (i.e. IF-PT and/or
IF-PB) is more challenging.
(PS. I'm thinking that currently a vendor [e.g. AV vendor]
needs to implement both sides of the handshake across IF-PA. Thus pretty much
interoperability with only itself:)
cheers,
/thomas/ From: Barbara Nelson [mailto:bnelson at ipass.com] Sent: Tuesday, January 31, 2006 11:36 AM To: THardjono at SignaCert.com; Susan Thomson (sethomso); nea at ietf.org Cc: Steve Hanna; Hardjono, Thomas Subject: RE: [Nea] Draft NEA WG charter: Please review 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