Re: [Nea] Protecting L2 PT when proxying
Mike Fratto <mfratto@gmail.com> Sat, 06 August 2011 14:21 UTC
Return-Path: <mfratto@gmail.com>
X-Original-To: nea@ietfa.amsl.com
Delivered-To: nea@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF99021F875C for <nea@ietfa.amsl.com>; Sat, 6 Aug 2011 07:21:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sozU6AMDfAZy for <nea@ietfa.amsl.com>; Sat, 6 Aug 2011 07:21:22 -0700 (PDT)
Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id D4C4921F873D for <nea@ietf.org>; Sat, 6 Aug 2011 07:21:21 -0700 (PDT)
Received: by iye1 with SMTP id 1so5213527iye.27 for <nea@ietf.org>; Sat, 06 Aug 2011 07:21:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1H+vDZ16bG6bsnM/L/RRDvSQloBjWnJxPsqitxIZysI=; b=OkjOrWX3mxP/Lpgpr7d7ZquOmY2fHEURqjmNrHETbAckUqyBe4UYG+VUs/gwgnsjVF 86azOPu0gAUa2BB9uIyzZhHDvXXYEPS/Cp0ZIB84hDIsNI5grWjYagOxWhzhkMJkW31z ie7MZ3JKn3e/JXqNiRS4lrPCeJwaVARVX5gfc=
MIME-Version: 1.0
Received: by 10.231.251.143 with SMTP id ms15mr1435661ibb.62.1312640500501; Sat, 06 Aug 2011 07:21:40 -0700 (PDT)
Received: by 10.231.152.66 with HTTP; Sat, 6 Aug 2011 07:21:40 -0700 (PDT)
Received: by 10.231.152.66 with HTTP; Sat, 6 Aug 2011 07:21:40 -0700 (PDT)
In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AEB728E99EC1@EMBX01-WF.jnpr.net>
References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> <AC6674AB7BC78549BB231821ABF7A9AEB6D0969659@EMBX01-WF.jnpr.net> <5A2C9B76-7BC5-48A5-B5DC-C9E99E135B29@cisco.com> <AC6674AB7BC78549BB231821ABF7A9AEB6D09699E9@EMBX01-WF.jnpr.net> <CB0D88DA-97CA-42E8-8C5E-B6E46F8F67F8@cisco.com> <AC6674AB7BC78549BB231821ABF7A9AEB7286BF210@EMBX01-WF.jnpr.net> <9CF77382-FF31-4ADA-9A56-64A23380FABF@cisco.com> <AC6674AB7BC78549BB231821ABF7A9AEB728E99EC1@EMBX01-WF.jnpr.net>
Date: Sat, 06 Aug 2011 10:21:40 -0400
Message-ID: <CADBETLy9+6QPxYMHm7PBX19vFzkW2sS7-5cS4NwYz_-ovjXc4A@mail.gmail.com>
From: Mike Fratto <mfratto@gmail.com>
To: Stephen Hanna <shanna@juniper.net>
Content-Type: multipart/alternative; boundary="000e0cdfc8bec00b6e04a9d6eef6"
Cc: "nea@ietf.org" <nea@ietf.org>
Subject: Re: [Nea] Protecting L2 PT when proxying
X-BeenThere: nea@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Endpoint Assessment discussion list <nea.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nea>, <mailto:nea-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nea>
List-Post: <mailto:nea@ietf.org>
List-Help: <mailto:nea-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nea>, <mailto:nea-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Aug 2011 14:21:23 -0000
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" <shanna@juniper.net> 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:jsalowey@cisco.com] >> Sent: Thursday, August 04, 2011 1:21 AM >> To: Stephen Hanna >> Cc: nea@ietf.org >> 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: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 >> >>> >> > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea
- [Nea] Consensus check on EAP-based PT Susan Thomson (sethomso)
- Re: [Nea] Consensus check on EAP-based PT Ira McDonald
- Re: [Nea] Consensus check on EAP-based PT Stephen Hanna
- Re: [Nea] Consensus check on EAP-based PT Sanchez, Mauricio (HP Networking)
- Re: [Nea] Consensus check on EAP-based PT Hao Zhou
- Re: [Nea] Consensus check on EAP-based PT Frank Yeh Jr
- Re: [Nea] Consensus check on EAP-based PT Alan DeKok
- Re: [Nea] Consensus check on EAP-based PT Andreas Steffen
- Re: [Nea] Consensus check on EAP-based PT Joe Salowey
- Re: [Nea] Consensus check on EAP-based PT Klaas Wierenga
- Re: [Nea] Consensus check on EAP-based PT Lisa Lorenzin
- Re: [Nea] Consensus check on EAP-based PT Marc Linsner
- [Nea] Protecting L2 PT when proxying Stephen Hanna
- Re: [Nea] Consensus check on EAP-based PT Mike Fratto
- Re: [Nea] Consensus check on EAP-based PT john.willis
- Re: [Nea] Protecting L2 PT when proxying Joe Salowey
- Re: [Nea] Consensus check on EAP-based PT Joe Salowey
- Re: [Nea] Consensus check on EAP-based PT Jouni Malinen
- Re: [Nea] Protecting L2 PT when proxying Stephen Hanna
- Re: [Nea] Consensus check on EAP-based PT Nancy Cam-Winget
- Re: [Nea] Protecting L2 PT when proxying Joe Salowey
- Re: [Nea] Consensus check on EAP-based PT latze@angry-red-pla.net
- Re: [Nea] Protecting L2 PT when proxying Stephen Hanna
- Re: [Nea] Protecting L2 PT when proxying Mike Fratto
- Re: [Nea] Protecting L2 PT when proxying Joe Salowey
- Re: [Nea] Consensus check on EAP-based PT kaushik narayan
- Re: [Nea] Consensus check on EAP-based PT Paul Sangster
- Re: [Nea] Consensus check on EAP-based PT Stephen McCann