attachment-0001
Hi,<br><br>FYI - the IETF AD has decided in favor of PT-EAP<br>(the TCG-aligned, widely deployed choice) for the <br>NEA Layer 2 Posture Transport protocol.<br><br>This moves the IETF NEA suite to full compatibility <br>w/ the TCG TNC suite.<br>
<br>Cheers,<br>- Ira<br><br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Stephen Farrell</b> <span dir="ltr"><<a href="mailto:stephen.farrell@cs.tcd.ie">stephen.farrell@cs.tcd.ie</a>></span><br>
Date: Wed, Aug 24, 2011 at 6:42 PM<br>Subject: Re: [Nea] Results of Consensus check on EAP-based PT<br>To: Susan Thomson <<a href="mailto:sethomso@cisco.com">sethomso@cisco.com</a>><br>Cc: <a href="mailto:nea@ietf.org">nea@ietf.org</a><br>
<br><br><br>
Hi all,<br>
<br>
The requested decision is at the end, so you can skip<br>
there first if you're only keen on the outcome:-)<br>
<br>
Firstly, I entirely agree with the WG that picking one<br>
way to do this is the way to go - other WGs with which<br>
I've been involved have regretted standardising two<br>
ways to do the same thing for years afterwards, so<br>
thanks for being open to even a pretty unqualified<br>
selection process, (i.e. having me pick) - I think<br>
you're doing the right thing in pushing hard for one<br>
standard. I'd also like to thank the chairs for<br>
their leadership of what could have been a quite<br>
divisive discussion - they're either good at that or<br>
else you're all much more polite than the average<br>
set of IETF participants:-)<br>
<br>
Second, I also agree with the WG that basically either<br>
approach could work so there's not much difference<br>
here, and that's probably one of the reasons why its<br>
been hard to reach a decision.<br>
<br>
Third, I also agree with the chairs that there is<br>
no rough consensus in the WG, neither on the list nor<br>
at the last couple of face to face meetings.<br>
<br>
My own reading of the situation is that PT-EAP<br>
does provide a firmer basis on which to go forward<br>
at this stage, given that there are implementations<br>
that have been deployed that are very similar.<br>
<br>
That was also backed up by a few off-list responses<br>
I got from people who know more about this than I<br>
but who are not involved in the WG. When I asked<br>
which way they thought would be better, one said<br>
doing it in EAP is crazy for size reasons, but most<br>
(4 to 2) said that the running code should win.<br>
<br>
However, I also agree with the argument that EAP-TLV<br>
is more in line with the direction in which EAP<br>
standardisation has been going, i.e. avoiding new<br>
less-secure EAP method definitions. OTOH, there are<br>
so many existing EAP methods, that its hard to see<br>
this as a showstopper.<br>
<br>
The other thing that strikes me is that neither<br>
approach is yet fully baked, in particular, the<br>
WG will still need to figure the detail of how<br>
to handle requirement PT-2 from RFC 5209, copied<br>
below:<br>
<br>
"PT-2 The PT protocol MUST be capable of supporting mutual<br>
authentication, integrity, confidentiality, and replay<br>
protection of the PB messages between the Posture Transport<br>
Client and the Posture Transport Server."<br>
<br>
My feeling is that the two already-similar proposals<br>
might look even more similar when a solution meeting<br>
that requirement is developed in the WG. (That solution<br>
might involve just an EAP tunnel or maybe more.) And<br>
that might (or might not) lead to a change in the WG<br>
consensus depending on how that solution looks. If a<br>
change in the WG opinion did happen later on I don't<br>
believe that switching to TLVs would be that much work at<br>
that point (as otherwise the WG consensus would presumably<br>
not be for change), so even if a change were done later<br>
I don't see it adding much delay. But of course, we<br>
don't want to get wedged again on a lack of consensus.<br>
<br>
So, taking all the above into account, I propose the<br>
following:<br>
<br>
- Proceed with PT-EAP: make draft-hanna-nea-pt a WG draft,<br>
and develop that until its ready for WGLC<br>
- At WGLC time, if called upon to do so by a WG participant,<br>
the chairs are to hold a new consensus call to see if<br>
WG consensus has in fact moved to using TLVs rather than<br>
an EAP method, *but* with a default that no consensus<br>
for change to TLVs at that point means staying with the<br>
EAP method approach of PT-EAP<br>
<br>
Note that this does not call for the proponents of<br>
EAP-TLV to continue developing their approach independently.<br>
My hope is that they get involved with the WG document and<br>
then, when that's ready, make their argument for a<br>
change to TLVs again, if they still feel that's useful.<br>
<br>
Regards,<br><font color="#888888">
Stephen.</font><div><div></div><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Nea mailing list<br>
<a href="mailto:Nea@ietf.org" target="_blank">Nea@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/nea" target="_blank">https://www.ietf.org/mailman/<u></u>listinfo/nea</a><br>
</div></div></div><br>
<br />--
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.