Re: [Nea] Protecting L2 PT when proxying

[Stephen Hanna <[e-mail]>]

Definitely! I expect we'll require L2 PT implementations to support the EAP tunnel method being standardized in EMU. That will give us a complete stack of Standards Track RFCs, from IF-M down to EAP.

Thanks for pointing this out, though. There's no such requirement now in either of the PT proposals.

Steve

Sent from my Verizon Wireless 4GLTE smartphone

----- Reply message -----
From: "Mike Fratto" <[e-mail]>
To: "Stephen Hanna" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [Nea] Protecting L2 PT when proxying
Date: Sat, Aug 6, 2011 10:21 am




Steve, I think one, maybe more, PT protection method needs to explicitly defined as a MUST otherwise you run the risk of conformant but non-interoperable implementations.

On Aug 5, 2011 5:38 PM, "Stephen Hanna" <[e-mail]<mailto:[e-mail]>> wrote:
> Joe,
>
> Neither proposed PT method includes confidentiality or
> integrity protection. Both are dependent on an enclosing
> tunnel to provide those protections. Everyone has agreed
> that we will include explicit language in the final NEA
> L2 PT specification, prohibiting sending L2 PT messages
> without proper security protections. The risks and
> countermeasures here are the same for the two proposals.
>
> You may believe that the risks are greater with an EAP
> method but many developers have proxied posture TLVs
> over RADIUS without protection. The risk is the same
> for both proposals.
>
> I'm fine with prohibiting the use of whatever proposal
> we agree on outside a tunnel. I'm just pointing out that
> using RADSEC for proxying provides a tunnel also and
> there's no rational reason to prohibit that.
>
> Let me try moving on to a constructive suggestion.
> Maybe we should consider making our L2 PT safe for
> proxying outside a tunnel by adding encryption,
> authentication, integrity protection, etc. We could
> derive a key from TLS-Unique. This could work for
> either of the proposals. And that should address your
> concern about defining a new EAP method that's not
> safe for use outside a tunnel. It would even make
> PT-EAP a true authentication method, although the
> identity established would only be "one of the
> endpoints for TLS tunnel X."
>
> Thanks,
>
> Steve
>
>> -----Original Message-----
>> From: Joe Salowey [mailto:[e-mail]<mailto:[e-mail]>]
>> Sent: Thursday, August 04, 2011 1:21 AM
>> To: Stephen Hanna
>> Cc: [e-mail]<mailto:[e-mail]>
>> Subject: Re: Protecting L2 PT when proxying
>>
>>
>> On Aug 3, 2011, at 5:47 PM, Stephen Hanna wrote:
>>
>> > 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.
>>
>> [Joe] For over 10 years we have been developing EAP methods that do not
>> need extra protection. Why should we take a step backward with PT-EAP?
>> Methods that do not provide protection should not be used outside a
>> tunnel method, period. These weak methods are not something we should
>> be trying to promote in the IETF, let alone generate. If you are going
>> to use a weak EAP method then constrain it to a tunnel. Standard proxy
>> implementations do not look into the EAP attribute to extract the type
>> to determine how to protect the message. If you are going to proxy
>> data which is sensitive then it must not be placed in a generic EAP
>> attribute which is proxied without regard for protection. Instead,
>> place it in its own attribute so implementations can treat it correctly
>> by protecting the attribute or the entire packet.
>>
>> > 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.
>> >
>>
>> [Joe] My concern is not with my implementation and my developers, but
>> rather that you are creating a situation in which a developer or
>> deployer who is not familiar with your deviant use of EAP can introduce
>> security vulnerabilities into their networks. I understand how
>> tempting it is to try to leverage some of the properties of EAP and AAA
>> as a implementation short cut, however it is often the case that
>> implementation short cuts lead to security vulnerabilities.
>>
>> > Thanks,
>> >
>> > Steve
>> >
>> >>>> -----Original Message-----
>> >>>> From: Joe Salowey [mailto:[e-mail]<mailto:[e-mail]>]
>> >>>> Sent: Wednesday, August 03, 2011 2:50 AM
>> >>>> To: Stephen Hanna
>> >>>> Cc: [e-mail]<mailto:[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]> [mailto:[e-mail]<mailto:[e-mail]>] On
>> Behalf
>> >>>> Of
>> >>>>>> Susan Thomson (sethomso)
>> >>>>>> Sent: Tuesday, August 02, 2011 5:04 PM
>> >>>>>> To: [e-mail]<mailto:[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]<mailto:[e-mail]>
>> >>>>>> https://www.ietf.org/mailman/listinfo/nea
>> >>>>> _______________________________________________
>> >>>>> Nea mailing list
>> >>>>> [e-mail]<mailto:[e-mail]>
>> >>>>> https://www.ietf.org/mailman/listinfo/nea
>> >>>
>> >
>
> _______________________________________________
> Nea mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/nea