From: Ira McDonald (blueroofmusic@gmail.com)
Date: Thu Mar 19 2009 - 13:45:16 EDT
Hi,
An observation about the extent of compatibility between IETF NEA and TCG TNC
specs. The IETF (and presumably TCG) specs for PB-TNC (Posture Broker) and
PA-TNC (Posture Attributes) *punt* security completely and say that's
the problem
of the PT (Posture Transport) component.
Although the IETF NEA charter says they will specify one 'mandatory to
implement'
transport, *nothing* in any published IETF NEA WG I-D ever does so.
PWG IDS can't write a binding to IETF NEA, because there's no transport, no
authentication, no integrity, etc. Who knows what goes 'on the wire'?
Jerry and Randy - you guys have followed IETF NEA - is this magic
secure transport
sauce somewhere in IETF NEA WG minutes, or is it just not there to be found?
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music/High North Inc
email: blueroofmusic@gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Thu, Mar 19, 2009 at 1:22 PM, Randy Turner <rturner@amalfisystems.com> wrote:
>
> Hi All,
>
> After reading Brian's (and Lee's) minutes and notes from the TCG HCWG call,
> I had the following comments ....
>
> I would agree that conforming to the NEA specifications provides most, if
> not all, of the benefits of TNC. I always thought that the TCG should not
> be creating protocols but instead, should be defining "profiles" of existing
> protocols for compliance with an overall architectural recommendation. This
> is similar to what the OATH consortium (OpenAuthentication) has done. The
> OATH consortium is a marketing/business/technical organization that produces
> IETF drafts for standardizing "on the wire" protocols, and the consortium
> drives adoption. In this way, they're employing existing organizations
> that really know how to create protocol standards, and using the "paid"
> organization to drive marketing/business, and technical evangelizing.
>
> Regarding "Client-less" devices, Microsoft has defined a set of behaviors in
> their NAP documents for how "clientless" devices are to be treated by the
> network. It seems to be that work on "clientless" devices is more
> "policy-oriented" than "technically-oriented" and that "standardizing"
> behavior in this area may seem more site-specific, and difficult to mandate
> a "global" conformance text for how to treat clientless devices. As such, I
> think this may be something that could be "recommended" but not "mandated".
>
> Someone brought up the comment about remediation, and Steve Hanna commented
> that "relevant remediation instructions for HCDs would be worthwhile".
> I think he's suggesting looking at a "standard" for HCDs regarding
> remediation, which is a topic that came up on an earlier conference call
> discussing a "common" NAP plugin for Microsoft's health assessment
> architecture. No vendor on the call seemed to "leap in" and say we should
> do this.
>
> I would urge participants in these discussions to think about Steve's
> comments regarding the value of TNC/NEA protocols for devices WITHOUT TPMs.
> This may be a point of departure for devices that do and do not have a TPM,
> especially when/if the TCG starts defining formal certification processes.
> While a TPM may not be ABSOLUTELY required by the NEA/TNC specs, the "bar"
> may be set so high for certification (requirements) that a TPM, or the
> equivalent of a TPM, may be the only way to hit the bar. It would be
> interesting to see if the MS-NAP documents discuss compliance/requirements
> issues with regards to devices that DO NOT have a TPM. For instance, over
> time, will devices that DO NOT have a TPM be lumped into the "clientless"
> device category? Or basically, will there be a "third" category of device
> for devices that implement the TNC protocol but do not have a TPM?
>
>
>
> Randy
>
>
This archive was generated by hypermail 2.1.4 : Thu Mar 19 2009 - 13:45:24 EDT