Subject: RE: [Nea] Draft updated NEA charter for review

From: "Alper Yegin" <[email-masked]>
Date: Mon, 2 Oct 2006 15:49:05 +0300

Steve,

> PT is the transport for PA and PB. EAP (with accompanying
> EAP methods) is one option (but not the only one) for PT.
> This has always been the case.

Does the PT stack stop at the EAP layer at the bottom? I was under the
impression that it'd also include the EAP lower layer (the transport
protocol(s) for EAP). One way or the other, it'd be good to clarify what
layers are covered by the PT.

Alper

> 
> The NEA BOF in Montreal agreed to add a requirement for
> the NEA WG to identify a Mandatory To Implement PT.
> With that addition to our charter, it seems clear that
> we shouldn't try to identify the MTI PT now or build
> into the charter any assumptions about what that protocol
> will be. Deciding on the MTI PT is the work of the NEA WG.
> 
> Thanks,
> 
> Steve
> 
> -----Original Message-----
> From: Alper Yegin [mailto:[email-masked]]
> Sent: Friday, September 22, 2006 6:45 PM
> To: 'Susan Thomson (sethomso)'; [email-masked]
> Subject: RE: [Nea] Draft updated NEA charter for review
> 
> 
> Hi Susan,
> 
> The charter text does not mention "EAP", though it was mentioned in the
> earlier version and also in your updates list. Is the solution stack
> still
> based on EAP? Also, what exact layers are covered by "PT"?
> 
> Thanks.
> 
> Alper
> 
> > -----Original Message-----
> > From: Susan Thomson (sethomso) [mailto:[email-masked]]
> > Sent: Friday, September 22, 2006 8:37 PM
> > To: [email-masked]
> > Subject: [Nea] Draft updated NEA charter for review
> >
> > A draft updated charter is included below. It has been updated in
> > consultation with the security AD, Russ Housley, and includes the
> > outcome of consensus questions posed at the last BOF (first 3 items
> > below).
> >
> > The charter is the one reviewed prior to the last BOF with the
> following
> > updates:
> > * Vendor-specific attributes are required to be documented
> > * Identify mandatory-to-implement PT for interoperability
> > * Accommodate technologies for detecting lying endpoints
> > * Omit specific PT requirements re EAP
> >   (given the inclusion of mandatory-to-implement PT above)
> > * Clarifications that deployment modes may be "advisory" (no impact on
> > network access) or "mandatory" (network access impacted)
> > * Clarifications that remediation protocols not in scope
> >
> > Please let us know of issues as soon as possible, preferably no later
> > than Wed 9/27.
> >
> > Note that the milestone dates have NOT been updated yet.
> >
> > The charter will enter the review cycle in IESG shortly and a decision
> > taken re WG
> > formation.
> >
> > Apologies for delay and thanks for your patience.
> >
> > Thanks
> > Steve and Susan
> >
> > ------------------------------------------------
> > Proposed NEA WG Charter
> > September 21, 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 compliance to an organization's posture policy
> > and optionally restricting access until the endpoint has been updated
> to
> > satisfy the posture requirements. An endpoint that does not comply
> with
> > posture policy may be vulnerable to a number of known threats that may
> > exist on the network. The intent of NEA is to facilitate corrective
> > actions
> > to address these known vulnerabilities before a host is exposed to
> > potential attack.
> > Two deployment scenarios will be supported: advisory mode and
> mandatory
> > mode.
> > In advisory mode, an endpoint may be advised of the result of posture
> > assessment
> > and any recommended remediation actions, but is provided normal
> network
> > access
> > regardless of the result. In mandatory mode, a non-compliant endpoint
> is
> > given
> > restricted access to the network sufficient for remediation purposes
> and
> > any essential
> > services or denied access completely.
> >
> > Posture refers to the hardware or software configuration of an
> > endpoint as it pertains to an organization's security policy. Posture
> > may include knowledge that software installed to protect the machine
> > (e.g. patch management software, anti-virus software, host firewall
> > software,
> > host intrusion protection software or any custom software) is enabled
> > and up-to-date.
> > On network access and while connected, an endpoint supporting NEA
> > protocols can be
> > queried for such posture information in either advisory or mandatory
> > modes.
> >
> > Since NEA involves many different components from different vendors,
> > interoperation is highly desirable. The priority of the NEA working
> > group is to
> > standardize protocols at the higher layers in the architectures:
> > the Posture Attribute protocol (PA) and the Posture Broker protocol
> > (PB).
> > PA and PB will be designed to support a variety of lower layer
> > protocols.
> > When used with 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 non-standard 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 the PA and PB protocols, and an
> > overall
> > security analysis. It will also include generic requirements for the
> > protocol
> > transporting PA, PB: the Posture Transport protocol (PT). PT protocols
> > may  be
> > standardized in other WGs since these protocols may not be specific to
> > NEA. The NEA WG
> > will identify one mandatory to implement PT protocol to ensure
> > interoperability.
> >
> > 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. Vendor-specific attributes must
> > be documented in an RFC.
> >
> > The PB (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.
> >
> > The PT (Posture Transport) protocol (or stack of protocols) is
> suitable
> > for carrying
> > the PB protocol at the time of network connection, or shortly after.
> >
> > The NEA working group will not work on standardizing protocols other
> > than PA and PB at this time. Further work in the NEA WG or in other
> WGs
> > will be considered via the standard rechartering process after the
> > completion of these milestones.
> >
> > One commonly discussed issue with NEA systems is how to handle
> > compromised endpoints, whose reports of their own posture may not be
> > accurate. Detecting or handling such endpoints is out of scope of
> > the NEA WG. Work on PA will focus on attributes useful for assessing
> > posture of those endpoints reporting accurate information. However,
> > the protocols developed by the NEA WG must be designed to accommodate
> > emerging technologies for identifying and dealing with lying
> endpoints.
> >
> > Note that NEA is not intending to standardize protocols for
> remediation.
> >
> > NEA is intended to be used with new or existing tools that can be used
> > in
> > the absence of NEA. There is an open issue with respect to NEA
> > applicability
> > in deployment scenarios where the endpoint is owned by a party that is
> > different
> > from the organization providing network access.
> >
> > Milestones:
> >
> > NOTE: DATES TO BE UPDATED.
> >
> > 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:
> > * At IETF 67, review NEA Evaluation I-D
> >
> > 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

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

---

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Mon, 2 Oct 2006 12:18:57 -0400

Hi Alper

For MTI purposes, PT is defined to be the protocol that encapsulates PB.
It is up to the PT specification iself to identify what underlying
carriers are supported. 

To avoid confusion, we could remove the words "or stack of protocols"
from the definition of PT in the charter text.

Thanks
Susan

> Sent: Monday, October 02, 2006 8:49 AM
> To: 'Stephen Hanna'; [email-masked]