Background Book on Trusted Computing -- RE: [Nea] Revised draft NEA charter

["Thomas Hardjono" <thardjono at signacert.com>]

Vidya, 

After the NEA BOF in Dallas I received similar questions (including from
Marcus) about the TPM, trusted hardware roles, and Trusted Computing.

Trusted Computing is a reasonably new field and still work-in-progress.
Trying to explain the TPM hardware, functions, its uses in platforms etc
is a very involved process. (ps. The best presentation I have seen was
6-hour long:)

I would like to recommend the book by the HP folks on trusted computing
as background reading:

Trusted Computing Platforms: TCPA Technology in Context (Hardcover) by
Siani Pearson et al.

http://www.amazon.com/gp/product/0130092207/sr=8-1/qid=1148573971/ref=pd
_bbs_1/102-1837598-2810552?%5Fencoding=UTF8

Regards.

/thomas/



-----Original Message-----
From: Stephen Hanna [mailto:shanna at juniper.net] 
Sent: Thursday, May 25, 2006 7:28 AM
To: Narayanan, Vidya
Cc: nea at ietf.org
Subject: RE: [Nea] Revised draft NEA charter

Vidya,

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

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

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

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

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea