[Nea] Protecting L2 PT when proxying

Joe,

I have changed the subject line since we're pursuing a
different topic now.

We talked about this at length in the WG meeting last week.
I think we all agreed that both of the L2 PT proposals MUST
be carried in an EAP tunnel method or equivalent protection.
This will need to be an explicit requirement in the spec.

The same requirements should apply to proxying PT beyond
the end of the EAP tunnel method. For PT-EAP, the obvious
choice is to use RADSEC (RADIUS/TLS). For EAP-TLV, a new
RADIUS attribute could be created to solve the problem,
as you suggest. Or RADSEC could be used. But neither L2 PT
proposal is suitable for unprotected conveyance over an
untrusted network. I suppose we could revise the proposals
to include their own security measures so that they could
be carried without external protections. But this was never
a design goal for NEA. I don't see any reason to add it
now, especially in the middle of a consensus check.

Thanks,

Steve

> -----Original Message-----
> From: Joe Salowey [mailto:jsalowey@cisco.com]
> Sent: Wednesday, August 03, 2011 2:50 AM
> To: Stephen Hanna
> Cc: nea@ietf.org
> Subject: Re: [Nea] Consensus check on EAP-based PT
> 
> 
> On Aug 2, 2011, at 3:54 PM, Stephen Hanna wrote:
> 
> > <WG Chair Hat Off>
> >
> > I prefer option 1) PT-EAP.
> >
> > My reasoning is that PT-EAP has been thoroughly vetted and widely
> > implemented over the last five years. Also, it provides the best
> > foundation for important future extensions such as secure proxy,
> > as highlighted by Stefan Winter's recent comments on the NEA list.
> >
> [Joe] I disagree that the EAP method approach is a good direction to a
> secure proxy and other extensions.   Currently in RADIUS, EAP is
> carried directly within a RADIUS attribute with no additional
> protection.  For modern EAP methods this is not a problem, since they
> provide sufficient protection from various forms of attack (as they
> should since they are used on unprotected links).  We have spent a lot
> of effort moving away from EAP methods such as EAP-GTC and EAP-MD5 that
> are not strong.  PT-EAP is a step backwards in this regard.
> Implementations will now have to be concerned about the protection
> communications when an EAP attribute is being carried. Alternatively,
> if TLVs are used a new RADIUS attribute can be defined to proxy the
> data if necessary.  In addition, this attribute can be designed to
> provide the protection that is appropriate for NEA data.
> 
> > Thanks,
> >
> > Steve
> >
> > <WG Chair Hat On>
> >
> >> -----Original Message-----
> >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf
> Of
> >> Susan Thomson (sethomso)
> >> Sent: Tuesday, August 02, 2011 5:04 PM
> >> To: nea@ietf.org
> >> Subject: [Nea] Consensus check on EAP-based PT
> >>
> >> 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
> >> Nea@ietf.org
> >> https://www.ietf.org/mailman/listinfo/nea
> > _______________________________________________
> > Nea mailing list
> > Nea@ietf.org
> > https://www.ietf.org/mailman/listinfo/nea