From: Randy Turner (rturner@amalfisystems.com)
Date: Thu Mar 19 2009 - 14:47:40 EDT
For those without a TNC IF-T diagram handy, since the NEA PT
abstraction is related to the TNC IF-T interface, there are actually
could be one, or more than one, transport protocol involved with
transporting attributes between a device under assessment, and a
validator. The IF-T interface, and likewise the PT interface, is more
of a "virtual" circuit between device and validator.
In the EAP-TNC case, when the attributes leave a device, they're
carried in EAPOL, which carries EAP, or tunneled EAP, and then it gets
to a switch (LAN or AP), that might transcode the PB/PA protocol onto
RADIUS.
Because of the potential complexity of different layer-1 and layer-2
(and potentially layer 2.5) protocols involved, the PT and IF-T
transports are more or less "virtual".
But at the same time, both TNC and NEA (and MS) do place requirements
that any collection of underlying transports should adhere to....
Randy
On Mar 19, 2009, at 11:16 AM, Randy Turner wrote:
> Hi Ira,
>
> The PT protocol was, from the outset, meant to be an abstraction,
> but it relates to the IF-T interface in the TCG TNC specs.
>
> It's complicated, but the PT protocol is not one transport, but
> whatever "bootstrap" protocol is "in vogue" in the network community
> at any point in time, so it's intentionally left as an abstraction
> since it's difficult to choose and subsequently standardize "one"
> transport.
>
> The TCG TNC group has published "binding" documents for tunneling
> TNC in EAP, and I believe Microsoft has published a way to deliver
> attributes with DHCP.
>
> There may be other "layer 2.5" mechanisms produced in the future,
> which will naturally call for new binding documents, but the PA/PB
> protocols will only make "requirements" on these protocols and the
> core model (PB/PA) shouldn't have to change. Because of the
> sensitive nature of information in the PB/PA traffic, the major
> requirements would be integrity and some type of authentication,
> preferably mutual, but definitely client auth.
>
> I personally think the tunneled EAP method (see IF-T) will be the
> most widely deployed enterprise/campus technique for delivering TNC
> messages. You can also google for EAP-TNC, which I think would bring
> up appropriate links.
>
> Randy
>
>
> ----- Original Message ----- From: "Ira McDonald" <blueroofmusic@gmail.com
> >
> To: "Randy Turner" <rturner@amalfisystems.com>; "Ira McDonald" <blueroofmusic@gmail.com
> >; "Jerry Thrasher" <thrasher@lexmark.com>
> Cc: <ids@pwg.org>
> Sent: Thursday, March 19, 2009 10:45 AM
> Subject: Re: IDS> Minutes of TCG HCWG phone call
>
>
> 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 - 14:47:51 EDT