Subject: RE: [Nea] Revised draft NEA charter

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 24 May 2006 20:41:45 -0700

Please see comments inline.  

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

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

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

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? 

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

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? 

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

I believe the charter should clarify this. 

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

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

Perhaps you missed my disclaimer that explicitly said this is not a
service provider perspective? :) I don't work for an SP and never have.
In fact, I worked for years in the government enterprise space and have
been in the cellular world for only a few months - so, anything I've
said is an individual opinion keeping both of those use cases in mind. 

Regards,
Vidya

> Take care,
> Steve

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

---

From: "Marcus Leech" <[email-masked]>
Date: Thu, 25 May 2006 00:07:12 -0400

> not even totally convinced of this at the moment, but let's say that).
Indeed.  The "trusted hardware" in this case acts as a kind of notary 
function.
  It attests to things that it can't effectively test the essential 
truth of.  A compromised
  machine can hand the "trusted hardware" any arbitrary nonsense that is 
otherwise
  "believable" by the trusted hardware, and it will duly notarize it.

Even if the so-called "trusted" hardware encompassed the entire machine, 
trusting
  anything it had to say about its state would involve believing that 
all software
  is perfect.  It also involves removing any kind of "turing 
completeness" from
  the endpoint.  Which might be useful perhaps for cellphones, but certainly
  not general purpose computing platforms.

Here's a simplified example.   I assert that I'm Marcus Leech, of Nortel 
Networks.
  My e-mail system, in some very loose sense, attests to that "fact".  
But you have
  no way of independently verifying the essential "truth" of my 
assertion, at least
  not from the position of somebody reading this e-mail.   You could, of 
course,
  move on to query our HR department, locate my peers inside Nortel, and 
query
  *them* about who they think I am.  You'd get close to being able to 
believe
  in my assertion about myself.

Now, we move on to a Turing-Complete computing environment, in which we
  ask for a believable assertion about the state of its sanity.  If the 
environment
  was, in fact, insane (compromised), and we ask it "are you sane?", there's
  no way we can trust the answer.  If, on the other hand, the environment
  *isn't* insane (not compromised), then the value of the answer you get
  back is of questionable utility.  The TPM can't fix this.  While it 
may hold
  the signing keys, etc, very close to its chest, it is ultimately at 
the mercy
  of the machine and software environment that is its host.  For any 
general-purpose
  computing environment, the TPM can't really trust anything it's being 
told, and it
  will blindly notarize any damned-foolish thing it's handed by the host.

There's the whole "TPM-mediated secure boot sequence" kool-aid, which is 
supposed
  to allow you to have the machine be in a predictable state after 
boot.  What that says
  about the state of the machine at time bootime+N, is another 
(unsolvable) matter
  entirely.

Does any of this stuff actually help against machine compromise?  It 
certainly makes
  the writing of malware somewhat harder.  But it only takes 1 clever 
hacker to
  build a "generic TPM-circumvention engine", and every piece of malware on
  the planet will have that engine within weeks.

The question, then, is *how long will it take*, and is that time 
sufficiently long that
  the investment in TCG/NEA/NAC/NAP/TCPA will all have been worth it?

There are lots of folks who believe that that time *will* be 
sufficiently long.
  I rather have my personal doubts.  But in the general spirit of throwing
  down thumb-tacks, and oil-slicks to prevent the bad guy from gaining
  on you, I'm willing to see what happens...

---

From: "Stephen Hanna" <[email-masked]>
Date: Thu, 25 May 2006 10:28:24 -0400

Vidya,

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

> not even totally convinced of this at the moment, but let's 

This is a big discussion. I'll start a separate thread for it.

> patch update/notification process - is that what is being 

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.

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

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

> 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

---

From: "Stephen Hanna" <[email-masked]>
Date: Thu, 25 May 2006 10:39:03 -0400

Let's start a new thread on detecting compromised endpoints.
Can trusted hardware help? Other ideas? This is really a
separate topic worthy of a full discussion. Also, it keeps
coming up. Let's thrash this thing out thoroughly and then
we can ask people who raise this issue to start by reading
this thread (or a summary of it).

I think we should probably start the discussion by agreeing
that we're not going to standardize any of this stuff in
IETF. However, it is sort of within scope for NEA since
we're supposed to do a security analysis of the whole
problem and this issue ALWAYS comes up (for good reason).

I call this the "lying endpoint problem". What good is
an NEA system if a compromised endpoint can just lie about
its health? In my view, there are two answers:

1) Even if NEA only works for healthy endpoints, it's
   a good thing because it will make them keep their
   defenses up: get patches, turn on the firewall, etc.
   You can think of it as a public health campaign for
   the endpoints.

2) With trusted hardware (and maybe some systems with
   a tiny trusted hypervisor or such), endpoint compromise
   can be reliably detected.

I think the main area of debate is the item 2). Does it
actually work? So I'll send a separate email on that,
responding to this email. But I'd like to invite anyone
with more general comments to respond to this email directly.
I hope we can keep all the emails on this topic under
this thread so they will be easy to find 2-3 years
from now.

Thanks,

Steve