Subject: RE: [Nea] Draft NEA WG charter: Please review

From: "Barbara Nelson" <[email-masked]>
Date: Tue, 31 Jan 2006 11:35:59 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Thomas Hardjono
Sent: Tuesday, January 31, 2006 9:27 AM
To: 'Susan Thomson (sethomso)'; [email-masked]
Cc: 'Steve Hanna'; 'Hardjono, Thomas'
Subject: RE: [Nea] Draft NEA WG charter: Please review

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Susan Thomson (sethomso)
Sent: Tuesday, January 31, 2006 7:26 AM
To: [email-masked]
Cc: Steve Hanna
Subject: [Nea] Draft NEA WG charter: Please review

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Thomas Hardjono" <[email-masked]>
Date: Tue, 31 Jan 2006 11:46:28 -0800

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:[email-masked]] 
Sent: Tuesday, January 31, 2006 11:36 AM
To: [email-masked]; Susan Thomson (sethomso); [email-masked]
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: [email-masked] [mailto:[email-masked]] 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.

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: [email-masked] [mailto:[email-masked]] On Behalf Of Susan
Thomson (sethomso)
Sent: Tuesday, January 31, 2006 7:26 AM
To: [email-masked]
Cc: Steve Hanna
Subject: [Nea] Draft NEA WG charter: Please review

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

2. IF-PT (EAP method suitable for carrying posture information as well as
supporting authentication)

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:

September 2006:

--- requirements for IF -PT (EAP over IP transport layer e.g. EAP over UDP,
EAP over TLS)

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:

* 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