IDS> Minutes of TCG HCWG phone call

IDS> Minutes of TCG HCWG phone call

IDS> Minutes of TCG HCWG phone call

Ira McDonald blueroofmusic at gmail.com
Thu Mar 19 13:45:16 EDT 2009


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




More information about the Ids mailing list