Re: [Nea] Consensus check on EAP-based PT

[Paul Sangster <[e-mail]>]

My vote is for PT-EAP.

It's my current view that both proposals are very close functionally and I don't see a compelling reason to select a TLV based approach.  I believe we should follow RFC 5209 which discusses the selection criteria for NEA protocols.  Again both approaches meet most of the requirements, however PT-EAP is already fully documented in a public standards based spec.  If that's not enough, we have a lot of implementation experience with PT-EAP with 9 independent implementations, many plugfests, clarification updates to the original spec (factoring in implementer feedback) and even compliance tests using a test suite specifically designed to test implementations.  Also, I think we should consider the Tao of the IETF in this particularly: 
    "One of the "founding beliefs" is embodied in an early quote about the IETF from David Clark: "We reject kings, 
    presidents and voting. We believe in rough consensus and running code".

On the implementation side, we actually have the OpenSEA Alliance supplicant which supports EAP-TNC carrying PB-TNC and PA-TNC, so we know the stack works well together and the implementers have reported no significant or unusual issues during the development (not even to the EAP engine).

It sounds like the discussion about protection of the inner method (or TLVs) carrying the posture could be addressed by adding security to either proposal.  I've not been convinced this is a serious problem that we can solve with words in a specification, since the root cause seems to be administrator misconfiguration/use of a product potentially resulting in weak security.  Administrator errors are hard to solve in standards specs unless we preclude any compliant product from ever being configured to potentially be not secure.  This is difficult and doesn't allow for deployments where they have addressed the security threats via other countermeasures (e.g. link encryption, proxied EAP over an encrypted link, physical isolation, ...).  I do think we should require implementation of core security features, but requiring their use in all situations is something we would need to discuss more.

> 
> 
> 
> On Aug 2, 2011, at 2:04 PM, Susan Thomson (sethomso) wrote:
> 
> > At IETF81 and several prior IETF meetings, as well as on the mailing
> > list, the WG has evaluated the pros and cons of 2 architectural
> > approaches to carrying posture within an EAP tunnel method:
> >
> > - EAP method
> > http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-01.txt
> >
> > - EAP TLV.
> > http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt
> >
> > So far, there has been no WG consensus to adopt one architecture
> versus
> > the other. (At the recent F2F meeting in Quebec City, the consensus
> > check at the meeting showed an equal number in favor of each
> approach.)
> >
> > This email is a final call to determine WG consensus on the L2 PT
> > approach.
> >
> > The consensus check is to choose one of the following 3 options:
> > 1) PT-EAP approach
> > 2) NEA-TLV approach
> > 3) Neither (please state the reason if you choose this option)
> >
> > Please respond to the above question by Tues Aug 16 at 5pm PT. Please
> do
> > so even if you have already expressed your opinion, either at a WG
> > meeting or on the mailing list. The answer can be as brief as
> selecting
> > option 1), 2) or 3). If you would like to add your reasons for your
> > choice, that would be appreciated too, especially if you choose
> option
> > 3).
> >
> > If we have consensus on the mailing list, we will adopt the selected
> > approach.
> >
> > If we still do not have consensus, the WG chairs and AD (Stephen
> > Farrell) have agreed that the AD will make a decision. The proponents
> of
> > both approaches have agreed to abide by this decision. This
> resolution
> > plan was discussed at the F2F meeting at IETF81. This plan was also
> > communicated to the list in an email on Jun 30, 2011. No objections
> have
> > been received.
> >
> > In either case, the individual submission corresponding to the
> selected
> > approach will be adopted as a -00 NEA WG I-D, and we will proceed
> with
> > the normal process of editing the document within the WG.
> >
> > Thanks
> > Susan
> >
> > ------------------
> > References:
> > IETF81 audio session (start at approx 44 mins into session):
> > http://www.ietf.org/audio/ietf81/ietf81-2103-20110727-1256-pm.mp3
> >
> > IETF81 draft meeting minutes:
> > http://tools.ietf.org/wg/nea/minutes
> >
> > _______________________________________________
> > Nea mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/nea
> 
> _______________________________________________
> Nea mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nea