Subject: RE: [Nea] Revised draft NEA charter

From: "Stephen Hanna" <[email-masked]>
Date: Wed, 24 May 2006 07:19:51 -0400

Thanks for your questions and comments on the NEA charter.
I'm glad to have your participation and feedback. I will
address your comments inline.

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

Many customers find NEA systems worthwhile as a way of increasing
the health of their endpoints. Also, when combined with trusted
hardware and other techniques, NEA can be effective in detecting
compromised endpoints. As with all security, nothing is perfect.
But in many cases, NEA is a good layer of protection.

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

NEA can be done at or after network access. That's why the latest
version of the charter says:

   PT, the Posture Transport protocol, is a protocol (or stack of
   protocols) suitable for carrying the PB protocol at or after
   network connection.

Notice the "or after" part. Also, the requirements document says:

   2. NEA protocols MUST allow the NEA server to initiate requests for 
   posture information prior to network access and at any time after 
   the client has established an identity on the network (e.g. IP 
   address.)  This enables the NEA server to evaluate posture prior to 
   allowing access and to periodically re-validate systems already 
   admitted to the network to assure they are still in compliance with 
   the current policies.

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.

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

NEA is not restricted to EAP and certainly not just to 802.1x.
That's why it's important for PA and PB to be transport independent.
There are many ways to do NEA. EAP and 802.1x is just one.

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

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?

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.

Thanks again for your comments. I'm glad we're getting a
service provider perspective on this.

Take care,

Steve

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 May 2006 10:13:08 -0700

>charter. What do others think?

Yes, we need that in the charter. It was generally agreed to at the 
BoF, and it is somewhat unexpected for many NAC users.

>make the charter clearer on this point.

Yup. Again, many NAC users would expect that an IETF group would 
expect that they would be coupled.

--Paul Hoffman, Director
--VPN Consortium