Hi Randy,
Thanks for the details about the PT abstraction.
All - IETF PB-TNC *does* place specific requirements on the PT
on page 12 of draft-ietf-nea-pb-tnc-03.txt (6 March 2009):
3.3. Layering on PT
PB-TNC batches are carried over protocol bindings of the PT protocol,
which provides the interaction between a Posture Transport Client and
a Posture Transport Server. PB-TNC counts on PT to provide a secure
transport. In particular, PT MUST support mutual authentication of
the Posture Transport Client and the Posture Transport Server,
confidentiality and integrity protection for PB-TNC batches, and
protection against replay attacks. PB-TNC is unaware of the
underlying transport protocols being used. PB-TNC operates directly
on PT; no further layer of PB-TNC is expected.
Randy - I don't care whether TCG ever answers the mandatory-to-implement
specific PT question - but the IETF NEA WG *MUST* do so in order to fulfill
their charter - there's nothing in their charter about abstract will do.
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 2:16 PM, Randy Turner <rturner at amalfisystems.com> 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 at gmail.com>
> To: "Randy Turner" <rturner at amalfisystems.com>; "Ira McDonald"
> <blueroofmusic at gmail.com>; "Jerry Thrasher" <thrasher at lexmark.com>
> Cc: <ids at 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 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
>>>>>>