Subject: RE: [Nea] Revised draft NEA charter

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Wed, 17 May 2006 17:27:16 -0700

Hi Steve,

In the milestones, I saw PA & PB specs, but not any PT specs.
Shouldn't this group invite PT candidates as well?
Or will those be standardized in another WG, namely, EMU?

This is not clear to me. Also, probably mention something about our
relationship with EMU...as a clarification.

Thanks
Hormuzd

-----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: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 18 May 2006 00:06:26 -0400

> Or will those be standardized in another WG, namely, EMU?

And in any case it has to be explicitly stated where those specs are to
come from.

-----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,

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: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 18 May 2006 11:30:41 -0400

> Thanks for your prompt and clear response.

You're wlecome.

> The action plan agreed to on the mailing list in
> April included this item:
> 
> B) Revise proposed NEA charter to focus on
>    transport-independent PA and PB and
>    requirements for PTT 

Here's an excerpt from the High Level Architectural Requirements for
NEA, posted in May - as April is long gone:

  7. The PA, PB & PV interfaces defined by NEA must be agnostic of the
  transport i.e. PT interface.

Consensus at the last BOF was that PA, PB and PV are all to be defined.

> Therefore, PV is not considered in scope for NEA,
> at least not for now. We could perhaps consider
> working on it after we have finished the work items
> in our initial charter.

Phasing is good. Putting necessary components out of scope is not.
Posture Validators may not run on the same box as Server Broker.

> Why was the action plan defined in this way? Because
> the feedback from the first BOF was to focus on a
> single clear interoperability goal--client-server
> interoperability--and to avoid defining transport
> protocols since some exist already and in any case
> that is the domain of other working groups.

1. Clear interoperability is clearly the goal.
   Which is why an important piece of the puzzle - the
   protocol between Posture Validator and Server Broker -
   must be defined.

2. IETF usually deals exclusively with transport protocols - and nothing
else.

> From: Blumenthal, Uri [mailto:[email-masked]] 
> Sent: Wednesday, May 17, 2006 6:06 PM
> To: Stephen Hanna; [email-masked]
> Subject: RE: [Nea] Revised draft NEA charter
> 
> I don't see PV interface mentioned in the new charter - this omission
> should be fixed.
>  
> 
> Sent: Wednesday, May 17, 2006 6:00 PM
> To: [email-masked]

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 23 May 2006 18:12:06 -0700

Hi Steve,
An opening disclaimer - I am not really speaking from a service provider
perspective. I'm listing some general concerns I have about this work -
some may be workable in the case of enterprise environments, but would
be very concerning in the cellular world. 

I have the following general comments on the NEA work: 

1. NEA seems to have applicability in determining the health (i.e.,
posture) of "well-behaved (or non-compromised)" endpoints in the system.
I am not yet convinced that this is broad enough of a problem that
warrants the complexity of implementing this for various applications.
However, looking beyond this concern, some more comments below. 

2. The motivation for tying NEA to network access is not very clear to
me. Given that we aren't talking about compromised devices, why would
tying NEA operation to network access make sense? Also, the PS draft
talks about potentially having to perform NEA again if the state changes
or if policies requires a re-validation. If tied to network access, does
this mean re-authentication? The impact of adding more operations at the
time of network access could be quite undesirable. 

3. The need to carry posture data in EAP methods concerns me. This
implies that in order to perform NEA, a particular EAP method needs to
be used. I realize that the goal is to specify the use of tunneled
TLS-based methods (like TTLS or PEAP?), so that the actual protocol used
for client authentication could still be different (e.g., CHAP).
However, even that is a restriction, since it limits the use to a
tunneled TLS method. The cellular world is going a different direction
with EAP-AKA and I'm not sure that NEA would be a reason to switch to a
tunneled TLS method. Even in the enterprise world, many wired
deployments don't really use 802.1x - a Kerberos-based authentication is
often viewed as being sufficient here. Also, some enterprise WLAN
deployments end up using VPN-style security, rather than relying on
802.11i. So, the tie to EAP-based access does not seem to be a universal
solution at all here. 

At this point, I am refraining from getting into more detailed comments.
At a minimum, I'd like the charter to clearly state the fact that this
work does not deal with device compromises and the impact of that. Also,
I personally think that de-coupling the NEA operation from network
access is needed to make this work somewhat more useful. 

Regards,
Vidya

> Sent: Friday, May 19, 2006 1:50 PM
> To: Narayanan, Vidya; [email-masked]
> 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
> > 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
> > 
> > > 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.
> > > 
> > > 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.
> > > 
> 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.
> > > 
> > > 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).
> > > 
> > > 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 
> > > * Resolve outstanding Last Call comments on requirements 
> I-D at IETF 
> > > 69
> > > 
> > > August 2007:

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 26 May 2006 18:43:49 -0700

Steve,

> 
> Vidya,
> 
> Sorry I mischaracterized your comments as coming from a 
> service provider perspective. Whatever the perspective, I 
> appreciate them.
> 

No worries. 

> > I don't see how NEA can detect compromised endpoints even 
> with trusted 
> > hardware - with trusted hardware storing the attributes, it 
> just means 
> > that a compromised device may not be able to tweak the 
> attributes (I'm 
> > not even totally convinced of this at the moment, but let's 
> say that).
> 
> This is a big discussion. I'll start a separate thread for it.
> 

I'm slowly catching up with that thread. I'll respond to this point on
that thread. 

> > > Re-validation after an IP address has been assigned would 
> typically 
> > > (but not necessarily) be done via a layer 3 protocol, 
> thus avoiding 
> > > the need to disrupt network access during the re-validation.
> > > 
> > 
> > Having said this, what is the result of posture validation? 
> > The analogy
> > I am able to make in my mind is something like a virus or 
> application 
> > patch update/notification process - is that what is being 
> > standardized?
> 
> The results of posture validation can include remediation or 
> restrictions on network access. For validation some time 
> after network access has already been granted, restricting 
> network access may use RADIUS CoA message, for example. 
> Remediation is the process of fixing problems with the 
> endpoint, manually or automatically.
> It can include installing patches or updates to the operating 
> system, applications, or virus definitions. That's common. It 
> can also include changes to configuration settings on the 
> endpoint (like enabling the firewall) and other things like 
> doing a virus scan.
> 
> The current NEA charter does not propose to standardize what 
> happens after posture validation. It's focused on the 
> protocols for posture validation itself.
> 

Right, I do understand this. In order to appreciate the charter and the
work, I was, however, trying to piece the big picture together. 

> > The charter says "It will also include requirements for the 
> protocol 
> > transporting PA, PB: the Posture Transport protocol (PT). Specific 
> > requirements for an EAP instantiation of PT will be identified." - 
> > this seems to imply that the primary protocol intended to 
> carry PA and 
> > PB is an EAP method. Or, am I missing something?
> 
> That darn sentence has been causing all sorts of trouble! ;-) 
> The NEA charter is supposed to be transport independent. But 
> people are definitely interested in EAP. It's a very popular 
> transport, supported by all the major NAC architectures but 
> in incompatible ways. So it was suggested that we should 
> include specific requirements for EAP so that the EMU group 
> or someone else could work on a standard transport for NEA if 
> they want to at some later time.
> 
> Maybe the sentence should be changed to something like this:
> 
> Specific requirements for an EAP instantiation of PT will be 
> identified in case standardization in that area is desired.
> However, standardization of an EAP instantiation is not in 
> scope for the NEA working group.
> 

The wording itself is okay, but I am trying to see what the deployment
model is likely to be, given what NEA is standardizing and what it may
ask other WGs in the IETF to standardize. Right now, I'm only seeing EAP
as the alluded solution and that in general concerns me. 

Regards,
Vidya

> > > The requirements document includes a discussion of device 
> compromise 
> > > in its security considerations section (8.1).
> > > Maybe we will need to include something about this in the 
> charter. 
> > > What do others think?
> > 
> > I believe the charter should clarify this. 
> 
> We seem to have consensus on this. Let's add a paragraph on 
> this topic to the charter once we agree on what it should say. ;-)
> 
> > > As for de-coupling NEA from network access, that's 
> already part of 
> > > the plan (as described above). Maybe we need to make the charter 
> > > clearer on this point.
> > > 
> > 
> > Aside from the confusions mentioned above, when it is 
> de-coupled from 
> > network access, it is not clear to me as to where the transport 
> > protocol is going to be specified.
> 
> There are other working groups better suited for such work.
> For instance, an EAP method should probably go through the 
> EAP or EMU working groups. I don't think our charter should 
> call out work for other working groups. That got us into 
> trouble last time. I hope the text on this that I proposed 
> above will help clarify it.
> 
> Thanks,
> 
> Steve
>