Re: [Nea] Protecting L2 PT when proxying

[Joe Salowey <[e-mail]>]

On Aug 5, 2011, at 2:38 PM, Stephen Hanna 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.
> 

[Joe]  The problem is that the default behavior in proxying EAP attributes is to proxy them unprotected.  We have spent a lot of time developing EAP method that are secure under this behavior.  Now you are introducing a new EAP method with additional protection requirements.  I believe this is a risk given the state of current standards-based deployments.  

> 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."
> 

[Joe]  I don't quite follow your proposal, it seems complex to protect data beyond the tunnel using the tunnel.  Here is my suggestion:  

1. Exchange PA data within the EAP tunnel method.   I would prefer this to be in a TLV, but It could be an EAP method if that is the decision.  
2.  When you are transporting the PA data outside the tunnel define a specific AAA attribute to carry it (do not use the EAP attribute).  Make this new attribute an encrypted attribute.  

This way proxies that understand the must explicitly apply protection that is appropriate for the attribute.  A current proxy implementation that does not understand this attribute will just forward encrypted data.  This way we do not have to redefine the behavior of the standard attribute. 


> Thanks,
> 
> Steve
> 
>> -----Original Message-----
>> From: Joe Salowey [mailto:[e-mail]]
>> Sent: Thursday, August 04, 2011 1:21 AM
>> To: Stephen Hanna
>> Cc: [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]]
>>>>>> 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
>>>>> 
>>> 
>