From: Randy Turner (rturner@amalfisystems.com)
Date: Fri Mar 20 2009 - 02:10:41 EDT
Sorry about that...I misread your earlier message -
I don't recall a discussion on "concrete" PT protocol selection on the
mailing list, but then again the mailing list doesn't seem to be very
active.
However, if and when this charter item is addressed, I am of the
opinion that the selection will be EAP-based, since a majority of the
TNC IF-T document bindings seem to center on this architecture.
Randy
On Mar 19, 2009, at 1:13 PM, Ira McDonald wrote:
> Hi Randy,
>
> NOT our PWG IDS charter - it's fine.
>
> The IETF NEA Charter requires that the NEA WG select exactly
> one mandatory-to-implement transport. The IETF NEA answer to that
> question is interesting to the PWG.
>
> "The NEA WG will identify and specify the use of one mandatory
> to implement PT protocol that is fully documented in an RFC."
>
> http://www.ietf.org/html.charters/nea-charter.html
>
> The IETF NEA answer to that question is interesting to the PWG.
>
> The PWG IDS WG will write as many specific protocol bindings
> as necessary, but a binding simply to NEA PB is useless for
> interoperability certification by any real security lab anywhere.
>
> 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 3:10 PM, Randy Turner <rturner@amalfisystems.com
> > wrote:
>>
>> Hi Ira,
>>
>> We can choose one particular "virtual" transport to mandate as a
>> standard,
>> but from a business requirement perspective, that probably won't
>> do. I
>> think vendors will adopt both EAP and DHCP as a way to transport
>> attributes,
>> at least initially. More may follow.
>>
>> Also, if the IETF NEA working group doesn't feel "omniscient"
>> enough to
>> mandate only one method, how much "cache" does the PWG have in
>> doing so?
>>
>> We may want to review the charter again...
>>
>> R.
>>
>>
>> On Mar 19, 2009, at 12:03 PM, Ira McDonald wrote:
>>
>>> 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@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@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@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 : Fri Mar 20 2009 - 02:10:55 EDT