Subject: [Nea] Revised draft NEA charter

From: "Stephen Hanna" <[email-masked]>
Date: Wed, 17 May 2006 17:59:41 -0400

Folks,

Susan and I have revised the draft NEA WG charter to reflect
the consensus of the mailing list as reflected in the NEA Action
Plan agreed to in April.

Please review this draft and send feedback ASAP. Of course,
we can revise the charter up to Montreal but I'd like to get
a solid version by Friday so we can submit our BOF proposal
on Monday as the IESG has requested.

Thanks,

Steve

-------------

Draft NEA WG Charter
May 17, 2006 Version

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.

Since NEA involves many different components from different vendors,
interoperation between NEA architectures and implementations is highly
desirable. Given that well-established protocols already exist for the
lowest layers in the NEA architectures (such as EAP and RADIUS), the
priority of the NEA working group is to standardize protocols at the
higher layers in the architectures (known as PA and PB and described
later). When used with the existing standards for lower layers, these
new protocols will allow interoperability between an NEA Client from
one vendor and an NEA Server from another.

Since there are already several existing protocols at these higher
layers, the NEA working group will consider these existing protocols
as candidates for standardization. A requirements document will be
written and used as a basis for evaluating the candidate
protocols. The working group may decide to standardize one of the
candidate protocols, use one of them as a basis for a new or revised
protocol, or decide that a new protocol is needed.

The NEA Requirements document will include a problem statement,
definition of terms, requirements for PA, PB, and an overall security
analysis. It will also include requirements for the protocol
transporting PA, PB (known as PTT and described below).

PA, the Posture Attribute protocol, consists of posture attributes
that are carried 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. Certain posture attributes
will be standardized to ensure interoperability but vendor-specific
attributes will also be supported.

PB, the Posture Broker 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.

PTT, the Posture Transport Tunnel protocol is a transport protocol
suitable for carrying the PB protocol at or after network connection.

Milestones:

June 2006:
* Submit first version of NEA Requirements I-D

July 2006:
* Agree on charter and milestones at IETF 66

September 2006:
* WG Last Call on NEA Requirements I-D 

October 2006:
* Deadline for submission of candidate specs for PA and PB
* Submit first version of NEA Evaluation I-D 

November 2006:
* Review NEA Evaluation I-D at IETF 67

December 2006:
* WG Last Call on NEA Evaluation I-D

January 2007:
* Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC
* Submit first draft of PA and PB specs for review

March 2007:
* Discuss unresolved issues with PA and PB specs at IETF 68
* Agree on solutions to unresolved issues with PA and PB specs

April 2007:
* Submit revised draft of PA and PB specs

June 2007
* WG Last Call on PA and PB specs

July 2007
* Resolve outstanding Last Call comments on requirements I-D at IETF 69

August 2007:
* Submit PA and PB specs to IESG for publication as Proposed

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 18 May 2006 02:55:36 +0300

> Given that well-established protocols already exist for the

Does the above text take the so-called "EAP lower layer" into consideration?
Examples in the bracket misses that aspect.

The earlier charter had said:

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.

Susan had stated that 802.1X is there for some specific deployments. That's
fine. But what about for those that require EAP/L3 as the previous charter
stated?

Alper

---

From: "Eugene Chang" <[email-masked]>
Date: Thu, 18 May 2006 10:03:50 -0400

I have some novice's questions. Since I am new to this group, I don't know
how significant these questions are to crafting a charter.

How tightly will the language defining PA, PB and PTT be interpreted for
defining the scope of work? The definitions generally match my intuition
about the problem. However I can read some constraints in the definitions
that do not match my long term views. Here are my questions below. Do these
need to be anticipated in the definitions in the charter?

PA, the Posture Attribute protocol. What is the proper interpretation for
what could qualify as an "attribute"? This definition works for me if an
attribute could be any data object. I would have reservations if an
attribute implies constraints on the richness of the data object.

PB, Posture Broker protocol. I read the definition to imply that given a set
of Posture Collectors and a set of Posture Validators, the PB strictly
partitions PCs into subsets and PVs into subsets so that a PC subset maps
one-to-one to a PV subset. This would recognize a near term reality that PC
subsets and PV subsets maybe from a single implementer (vendor) and that the
PB maintains the separation of PA between implementers (vendors). This
definition does not work for me if we envision a future where posture
attributes could flow between different implementers.

PTT, Posture Tunnel Transport protocol. I read this definition as a
transport for a bundle (set) of PB. This definition works were we see the
partitioning of the PC and PV. My concern here is the same as for the PB.

Thanks,
Gene

--------------------------------------------------------------------------
Eugene Chang
Meetinghouse
 
voice:       +1-603-610-8678
mobile:     +1-781-799-0233
fax:          +1-603-430-8436
email:       [email-masked]
email:       [email-masked]
skype:      gene02421

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]] 
Sent: Wednesday, May 17, 2006 6:00 PM
To: [email-masked]
Subject: [Nea] Revised draft NEA charter

Folks,

Thanks,

Steve

-------------

Draft NEA WG Charter
May 17, 2006 Version

Milestones:

June 2006:

July 2006:

September 2006:

October 2006:

November 2006:

December 2006:

January 2007:

March 2007:

April 2007:

June 2007

July 2007

August 2007:

---

From: "Stephen Hanna" <[email-masked]>
Date: Thu, 18 May 2006 15:09:17 -0400

As we all know, the "EAP lower layer" (protocols that carry
EAP) is somewhat standardized. Less so than EAP and RADIUS.
The rough consensus on the NEA mailing list after the last
BOF was that the NEA should not focus on standardization
in this area, at least not at this time. NEA should provide
requirements for transport protocols (PTT/PTC) based on
the needs of PA and PB but not otherwise address this area
for now.

I think the charter should be revised to make this clear.

Thanks,

Steve

> From: Alper Yegin [mailto:[email-masked]] 
> Sent: Wednesday, May 17, 2006 7:56 PM
> To: [email-masked]
> Subject: RE: [Nea] Revised draft NEA charter
>

---

From: "Stephen Hanna" <[email-masked]>
Date: Thu, 18 May 2006 15:27:44 -0400

Gene,

Thanks for your comments. Let me address your questions directly.

> attribute implies constraints on the richness of the data object.

As the charter says, both standard attributes and vendor-specific
attributes will be supported. I don't want to prejudge the work of
the NEA WG but I suspect that few constraints will be placed on the
contents or format of vendor-specific attributes.

> attributes could flow between different implementers.

Once standard attributes are defined, the one-to-one PC-PV pair model
breaks down. So I agree with you that such a model should not be
employed. I don't think the charter implies such a thing but maybe
the language could be clarified. Any suggestions?

> partitioning of the PC and PV. My concern here is the same as 

PTT is only "a transport protocol suitable for carrying the PB
protocol".
No implication about partitioning PCs and PVs was intended. I don't see
how it's implied by the current language. Could you point that out?
Maybe clarifying the description of PB will help. Or maybe we'll
just let people read the requirements document which will presumably
clarify this.

Thanks,

Steve

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 18 May 2006 23:59:34 +0300

Hi Steve,

I agree with what you are saying. In fact, what you said is aligned with the
earlier charter as I had quoted below. Than maybe we should restore that
text.

As you know, L3 transport for EAP is PANA. If we understand the
requirements, we can figure out what additional things need to be done, if
any. We may need to define NEA-specific AVPs, maybe.

Alper

> Sent: Thursday, May 18, 2006 10:09 PM
> To: Alper Yegin; [email-masked]

---

From: "Eugene Chang" <[email-masked]>
Date: Thu, 18 May 2006 22:12:11 -0400

Steve,
I reread the definition for the PB. 
"PB, the Posture Broker 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."

It maybe that the problem I described comes from my reading that the
definition allows for more than one instance of the PB. If there is more
than one instance, then the partitioning can happen. If there is only one PB
then there is no partitioning. 

I don't see a graceful way to change the wording to prevent a reading that
has more than one instance of the PB. I would agree to leaving the language
as is and leave further discussion to the requirements document.

Thanks for clarification.
Gene

voice:       +1-603-610-8678
mobile:     +1-781-799-0233
fax:          +1-603-430-8436

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]] 
Sent: Thursday, May 18, 2006 3:28 PM
To: [email-masked]; [email-masked]
Subject: RE: [Nea] Revised draft NEA charter

Gene,

Thanks,

Steve