Re: [Nea] Protecting L2 PT when proxying

[Stephen Hanna <[e-mail]>]

My comments are inline below.

Joe Salowey wrote:
> On Aug 3, 2011, at 7:28 AM, Stephen Hanna wrote:
> > 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.
> 
> [Joe] If you follow the above mandate then you would not expose PT-EAP
> outside the tunnel method.  I believe this is the appropriate
> requirement if using PT-EAP.

I don't agree. You should be able to use RADSEC to proxy PT-EAP
from an EAP server that terminates the EAP tunnel and authenticates
the user to a NEA Server that performs the posture assessment.

> > 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.
> >
> [Joe]  The problem here is that the EAP RADIUS attribute in general
> does not require additional protection.  PT-EAP introduces a new
> special case in which it does.  This creates a situation in which
> implementations need to check the EAP type code in order to change
> their behavior.    While this may seem harmless, it adds complexity and
> conspires against the extensible framework that EAP and AAA are built
> upon.   I agree that there are multiple ways to protect an attribute.
> When proxying NEA data as an EAP method you are overloading an existing
> attribute with new meaning and requirements, but with a TLV you would
> create a new attribute with its own protection requirements and
> possibly its own protection mechanism.   You can also create an
> attribute to carry PT data even if you are using PT-EAP, which would be
> my preferred approach if we are going to expose NEA data outside the
> tunnel.

PT-EAP is no more a special case than any of the other EAP methods
that cannot safely be used without protections. You may consider
this to be difficult to implement but several implementers have
already spoken out on the NEA list saying that they found an EAP-
based PT easier to implement than an attribute-based PT. I don't
question that PT-EAP might be harder for your employer to implement
since you've designed your architecture around using TLVs to carry
posture but apparently this does not hold for other implementations.

Thanks,

Steve

> >> -----Original Message-----
> >> From: Joe Salowey [mailto:[e-mail]]
> >> Sent: Wednesday, August 03, 2011 2:50 AM
> >> To: Stephen Hanna
> >> Cc: [e-mail]
> >> 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: [e-mail] [mailto:[e-mail]] On Behalf
> >> Of
> >>>> Susan Thomson (sethomso)
> >>>> Sent: Tuesday, August 02, 2011 5:04 PM
> >>>> To: [e-mail]
> >>>> 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
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/nea
> >>> _______________________________________________
> >>> Nea mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/nea
> >