Subject: RE: [Nea] Revised draft NEA charter

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 17 May 2006 19:13:57 -0700

A high level question - is the work solely targeting enterprise
environments? The problem statement alludes to this, but, this is not
clear from the charter. 

Thanks,
Vidya

> -----Original Message-----
> From: Stephen Hanna [mailto:[email-masked]] 
> Sent: Wednesday, May 17, 2006 3:00 PM
> To: [email-masked]
> Subject: [Nea] Revised draft NEA charter
> 
> 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
> 

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

---

From: "Stephen Hanna" <[email-masked]>
Date: Fri, 19 May 2006 16:49:42 -0400

I don't think the NEA work needs to be restricted to enterprise
environments. As the problem statement says, "Network assessment
architectures have been targeted primarily at enterprise deployment
scenarios to date." That's true of the past but I don't think it
needs to be the case in the future.

Could you review the charter and documents from a non-enterprise
point of view (service provider, I presume?) and point out any
deficiencies?

Thanks,

Steve

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Wednesday, May 17, 2006 10:14 PM
> To: Stephen Hanna; [email-masked]
> Subject: RE: [Nea] Revised draft NEA charter
>