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