From shanna@juniper.net Mon Aug 1 19:15:26 2011 Return-Path: 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 CF14021F8B26 for ; Mon, 1 Aug 2011 19:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.441 X-Spam-Level: X-Spam-Status: No, score=-106.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] 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 nHOplEOBxYIK for ; Mon, 1 Aug 2011 19:15:22 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id AB79421F84CA for ; Mon, 1 Aug 2011 19:15:20 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTjddqyWDIS4vx/5bL2vXddxKro4ZPB8L@postini.com; Mon, 01 Aug 2011 19:15:28 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 1 Aug 2011 19:14:37 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 1 Aug 2011 22:14:36 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Mon, 1 Aug 2011 22:14:35 -0400 Thread-Topic: Draft NEA WG minutes from IETF 81 Thread-Index: AcxQuexgvhPmquIBTXW4hOxj7ax98w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Nea] Draft NEA WG minutes from IETF 81 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 02:15:26 -0000 Included below is a first draft of the minutes for the NEA WG meeting at IETF 81. Thanks to Mauricio Sanchez and Kent Landfield for taking notes. I have combined their notes and added a bit of material from the audio recording of the meeting. Please review these minutes and send any comments or corrections to the nea@ietf.org email list by end of day August 15. Thanks, Steve ----------- Minutes of NEA WG Meeting at IETF 81 These notes do not attempt to duplicate the content of the slides. Instead, they summarize the material presented, and focus on comments and discussion. Notes taken by Mauricio Sanchez and Kent Landfield Agenda =3D=3D=3D=3D=3D=3D Date: Wednesday, July 27, 2011 Time: 1300-1500=20 WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 1300 Administrivia Jabber & Minute scribes Agenda bashing 1305 WG Status 1310 NEA Reference Model 1315 Discuss and Resolve Open PT-TLS Comments draft-ietf-nea-pt-tls-00.txt 1400 Discuss and Resolve EAP vs. TLVs for L2 PT draft-cam-winget-eap-tlv-03.txt draft-hanna-nea-pt-eap-01.txt 1500 Adjourn WG Status =3D=3D=3D=3D=3D=3D=3D=3D=3D Susan Thomson reviewed WG status. We now have a WG draft for the TLS-based transport. Please review and comment. Plan to do a WGLC on this soon. For the EAP-based transport, we have two competing proposals with no agreement yet. Today, we'll discuss the key differences between the proposals as agreed by the proponents. Maybe that will help us get WG consensus. If not, we have agreed that our AD will decide. NEA Reference Model =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Steve Hanna reviewed the NEA reference model for the benefit of those new to the WG. Discuss and Resolve Open PT-TLS Comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Paul Sangster described the latest PT-TLS specification, draft-ietf-nea-pt-tls-00.txt. The main new change is the addition of messages to carry SASL authentication. Paul asked several questions: 1) The SASL TLVs are mandatory to implement and optional to use. Is that OK? Nobody in the room objected. 2) The PLAIN and External SASL Mechanisms are mandatory to implement. Is that OK? Do we need any other mechanisms? We could include some as a SHOULD or a MAY. Paul pointed out that other commonly used SASL mechanisms include Kerberos or GS2, which supports certificate-based client authentication. Mike Boyle said that it would be extremely desirable to be able to do both user and device authentication using certificates, at least for certain circumstances. Paul suggested saying that if your implementation is intended to be used in environments where it's desirable to do both user and device authentication using certificates, then you SHOULD support GS2. Trevor Freeman pointed out that this is a tunneled authentication protocol but there's no channel binding. Paul described how the draft calls for TLS-Unique to be used to bind the TLS session to an External Measurement Agent like a TPM. Trevor said that when you use the Kerberos SASL mechanism, you must make the client prove possession of the shared secret. Paul said this could be done by hashing TLS-Unique with the Kerberos secret and having the TPM sign that hash. Joe Salowey asked whether the kitten WG has defined a way to do channel binding with SASL. Shawn Emery said they have with GS2. He's not sure if it will work for all mechanisms. Klaas Wierenga suggested supporting SCRAM since that supports channel bindings. Joe said GS2 is probably more useful for our use cases. Klaas said GS2 has lot of other benefits. Paul asked whether we should make GS2 a SHOULD. Shawn said yes. Joe said the important thing is to talk about channel bindings and how to do them with SASL. We can make it a MAY, as long as we explain how to do it. Paul agreed that he'll make GS2 a MAY and talk to the kitten folks about channel bindings so that we can explain how to do that properly. Paul said the next step is to publish a -01 draft (preferably in August) and then do a WGLC. We'll discuss any substantial comments from WGLC at IETF 82. Stephen Farrell asked about trust anchor storage. Will we have any guidance on that? Paul said that we don't know. Stephen said that we should so that people know not to just use the operating system's list of trust anchors. Discuss and Resolve EAP vs. TLVs for L2 PT =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Steve Hanna and Nancy Cam-Winget came to the front and gave a joint presentation on the key differences between the two competing proposals: PT-EAP and EAP-TLV. The presentation was only one slide but after each line on the slide there was discussion of that line. Here is a summary of the discussion. However, this cannot do justice to all the details given in the full discussion. For that, listen to the audio recording. Encapsulation: Steve favors using an EAP method to carry NEA messages. Nancy favors using a general container approach that can ride across many transports (including EAP). We are not really doing authentication, architecturally. Proxy:=20 Steve favors usage of EAP because facilitates proxy behavior, specifically the ability to proxy NEA exchanges beyond the end of the EAP tunnel method. Nancy feels the EAP framework is too tied to the authentication process/RADIUS too much. Should be about NEA client/server framework, not a AAA framework. Also, security of EAP-TNC not guaranteed. Nancy: Could have strong language in draft requiring strong protection for the NEA exchange. Joe: Sees proxying as not a useful feature. Spent a lot of time over 10 years moving away from insecure EAP methods. EAP-TNC introduces special cases to keep it secure. Steve: Proxying is clearly valued by some people. Stefan Winter recently emailed the NEA list, saying that proxying should have been included in the original NEA requirements. Clearly, any such proxying would need to be protected. Regardless of approach, our draft should mandate that the NEA exchange be strongly protected at all times. Joe: Feels that TLV approach allows security to be built into the design easier. Klaas: Thinks ability to proxy is very important. Can't assume trust relationship between client and server. Example is eduroam. Stefan Winter (via Jabber): Yes, proxying is a desirable property. But it's important to be able to blend together the result of the authentication with the NEA exchange. Joe: Proxying can mean different things. Proxying entire conversation can be done with either approach. Proxying components of the conversation does lead to a different capability. Implementations:=20 Nancy: The EAP-TLV approach is based on several existing working models. Microsoft SoH uses a TLV approach. Steve Hanna: PT-EAP is equivalent to EAP-TNC, which is a TCG spec that is 5 years old and has 9 independent implementations. There have been many security reviews and several papers written on EAP-TNC also. If we're talking about architecturally similar implementations (like SOH is to EAP-TLV), there are several proprietary implementations that use an EAP approach. Stephen Farrell: Asks about deployments of TCG specification. Steve H: Millions of users, however unclear how many are leveraging a close variant of EAP-TNC. Of course, the latest NEA transport drafts added TLS-Unique for use with hardware-based health checks. But nobody does that anyway, at least now. Nancy: Reiterated whether group really wants to promote what is an insecure EAP (EAP-PT). Steve responds that authentication could be added to our L2 PT if need be, but it was not a requirement since the EAP tunnel method handles that. EAP-TLV also has no built-in security. Architecture: Nancy: EAP-TLV uses a TLV transport since transport is the goal, not authentication. Using EAP for a non-authentication purpose causes problems. Steve H: As we saw in a discussion on the list recently, most EAP implementations today (like Windows 7) have a pluggable architecture for adding new EAP methods but not for adding new TLVs. Nancy retorts that it's exactly that pluggable architecture that highlights the opportunity to run PT-EAP unprotected. Nancy asks whether EAP tunnel methods handle multiple inner methods or whether they handle it consistently. Main point is that software upgrades will need to be done with either method. Joe S.: One additional concern between authentication vs. non-authentication is that the EAP RFCs define quantities that an EAP method should define, like peer ID and server ID. While you can operate without those, on the server side the lack of that information is problematic because it doesn't know what it should do if it needs to make authorization decisions. We may be able to special case, but all with additional complexity. Authentication/NEA sequencing: =20 Steve: EAP-TLV can run the NEA handshake in parallel with an EAP authentication. PT-EAP can't. There are some good reasons to do authentication in parallel with NEA handshake, but that can also introduce some undesirable traits. Some orgs want authz first then NEA, others reverse. Nancy: Early on identified need to do both serial and parallel approaches. = =20 Steve: EAP-TLV draft not entirely clear how serial and parallel should be done. Nancy: This can be cleaned up in future drafts. Key export: Steve: We used key export early on, before we decided to move to TLS-Unique. Very useful for binding the inner and outer EAP methods. At this point, value of being able to do key export is not as clear. Nancy: Design goal for EAP-TLV is just for a transport and not authentication. Moreover, key export capabilities in PT-EAP are suspect in security. Joe: Worried that design of key export in PT-EAP is fragile. Steve: Actually, key export was dropped from most recent draft of PT-EAP. Could be added back in but it's not in there now. Standards: Nancy: EAP-TLV is a new proposal. Steve: One of the requirements in the NEA Reference Model is that we have to prefer existing open standards. PT-EAP is definitely a standard. Whether you consider it open or not depends on your definition of open standards. It's available for free from the TCG web site and has been for five years. The I-D has been contributed to the IETF Trust so at this point it's up to IETF to decide what to do with it. Susan did a consensus check. Prefer PT-EAP? 6 in favor Prefer NEA-TLV approach? 6 in favor=20 Neither? 0 prefer neither Next Steps: Stephen Farrell (AD) discussed next steps given result. Stephen will be gathering opinions over the week online and offline. He will be thinking about it over next several weeks and make decision by the end of August. Then he'll post his decision to the NEA list. Steve H. asked for consensus check on process of having AD choose between PT-EAP and EAP-TLV. More than 12 people are OK with AD choose. Nobody is against. Nancy asked if we need to have a formal consensus check on process on the email list since WG chairs and ADs can make process decisions. Agreed that there's no need to have do a formal consensus check on that. However, we will do a formal consensus check on PT-EAP vs. EAP-TLV (2 weeks on the list) and we'll warn people that if that consensus check fails to produce a consensus, our AD will decide. Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Susan went through a new set of proposed milestones, as listed on the slides. There were no questions or comments. Meeting adjourned. From sethomso@cisco.com Tue Aug 2 14:04:21 2011 Return-Path: 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 EB63C21F8777 for ; Tue, 2 Aug 2011 14:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=-3.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 v1Uxm0bjhlrP for ; Tue, 2 Aug 2011 14:04:21 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6757A21F874E for ; Tue, 2 Aug 2011 14:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=2121; q=dns/txt; s=iport; t=1312319071; x=1313528671; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=hFmhbaKQPkjPw6l+dTBpLOlFhX4FD/UE0XnFOAZ/3aQ=; b=P4odMoS4AEwBlmDZLARXZID4niX/S/ZkLH6/BlcyyzrUTrYzDv7F3Ys6 /Uy2vKimb+OXc49/rd7CUe0DzAcD0T1XIvf4z/hJG7TLXWO0Q8wmqXRig uBG1uVwZ0xDlgjG60I0LE8i0tJwn9+QzMdZTCfXLk4r9tyR1Gh58gOAgV k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUHAC5lOE6tJXG+/2dsb2JhbABCmFaPEneBQgEBAxIBHQo0HQEaEAYYB0gPAQQbARmHTp9+gSMBnlWFY18Eh1qQMYty X-IronPort-AV: E=Sophos;i="4.67,307,1309737600"; d="scan'208";a="8963222" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 02 Aug 2011 21:04:31 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p72L4VB0025467 for ; Tue, 2 Aug 2011 21:04:31 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Aug 2011 16:04:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Aug 2011 16:04:25 -0500 Message-ID: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Consensus check on EAP-based PT Thread-Index: AcxRV8K12t9ayfNhRg2m5tY+ll6mrA== From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 02 Aug 2011 21:04:31.0177 (UTC) FILETIME=[C5F05B90:01CC5157] Subject: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:04:22 -0000 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:=20 - EAP method=20 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.=20 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):=20 http://www.ietf.org/audio/ietf81/ietf81-2103-20110727-1256-pm.mp3 IETF81 draft meeting minutes: http://tools.ietf.org/wg/nea/minutes From blueroofmusic@gmail.com Tue Aug 2 14:44:53 2011 Return-Path: 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 8D4A211E808F for ; Tue, 2 Aug 2011 14:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 6zRdOrn9AHbW for ; Tue, 2 Aug 2011 14:44:52 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E204211E8095 for ; Tue, 2 Aug 2011 14:44:51 -0700 (PDT) Received: by fxe6 with SMTP id 6so243762fxe.31 for ; Tue, 02 Aug 2011 14:45:01 -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=YRmliG3l9mmFcI9PifOC7PhYJwauoKelXF87ycBYGYY=; b=aSw/9SJKw8qdcJnxhBLzj6/Mx6vuJoNWRNPSEwlgl4XAOB5eme3jUgR1uELM46Gkdg OPdr7cOm/l1S3Ppm/TFLW+ZXRL9+OHWSI8eHc0PeIgeGPUp1AIHJFNBAYbVLC3JLMqu3 pXjDdqgRUXIMuESNtpkNbmz2g7yBYuxJL6zeQ= MIME-Version: 1.0 Received: by 10.223.16.210 with SMTP id p18mr6803532faa.71.1312321501164; Tue, 02 Aug 2011 14:45:01 -0700 (PDT) Received: by 10.223.19.68 with HTTP; Tue, 2 Aug 2011 14:45:01 -0700 (PDT) In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> Date: Tue, 2 Aug 2011 17:45:01 -0400 Message-ID: From: Ira McDonald To: "Susan Thomson (sethomso)" , Ira McDonald Content-Type: multipart/alternative; boundary=00151748de7ce877b304a98ca8d4 Cc: nea@ietf.org Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 21:44:53 -0000 --00151748de7ce877b304a98ca8d4 Content-Type: text/plain; charset=ISO-8859-1 Hi, Option 1 - PT-EAP Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - IEEE-ISTO PWG IPP WG Chair - TCG Embedded Systems Hardcopy SWG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Christmas through April: 579 Park Place Saline, MI 48176 734-944-0094 May to Christmas: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Tue, Aug 2, 2011 at 5:04 PM, Susan Thomson (sethomso) wrote: > 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 > --00151748de7ce877b304a98ca8d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Option 1 - PT-EAP

Cheers,
- Ira

I= ra McDonald (Musician / Software Architect)
Chair - Linux Foundation Ope= n Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Chair - TCG Embedded Sy= stems Hardcopy SWG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High Nort= h Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Christmas through April:
=A0 579 Park Place=A0 S= aline, MI=A0 48176
=A0 734-944-0094
May to Christmas:
=A0 PO Box 2= 21=A0 Grand Marais, MI 49839
=A0 906-494-2434



On Tue, Aug 2, 2011 at 5:04 PM, Susan Th= omson (sethomso) <sethomso@cisco.com> wrote:
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://t= ools.ietf.org/wg/nea/minutes

_______________________________________________
Nea mailing list
Nea@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/nea

--00151748de7ce877b304a98ca8d4-- From shanna@juniper.net Tue Aug 2 15:55:40 2011 Return-Path: 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 400A711E80C3 for ; Tue, 2 Aug 2011 15:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 xu9SBhKgjSli for ; Tue, 2 Aug 2011 15:55:39 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 636C611E8095 for ; Tue, 2 Aug 2011 15:55:39 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTjiAdcg4f244mPWTqWncMtM0XNg1WWZA@postini.com; Tue, 02 Aug 2011 15:55:49 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 2 Aug 2011 15:54:03 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 2 Aug 2011 18:54:03 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Tue, 2 Aug 2011 18:54:02 -0400 Thread-Topic: Consensus check on EAP-based PT Thread-Index: AcxRV8K12t9ayfNhRg2m5tY+ll6mrAADod2A Message-ID: References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 22:55:40 -0000 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. Thanks, Steve > -----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 >=20 > 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: >=20 > - EAP method > http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-01.txt >=20 > - EAP TLV. > http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt >=20 > 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.) >=20 > This email is a final call to determine WG consensus on the L2 PT > approach. >=20 > 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) >=20 > 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). >=20 > If we have consensus on the mailing list, we will adopt the selected > approach. >=20 > 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. >=20 > 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. >=20 > Thanks > Susan >=20 > ------------------ > References: > IETF81 audio session (start at approx 44 mins into session): > http://www.ietf.org/audio/ietf81/ietf81-2103-20110727-1256-pm.mp3 >=20 > IETF81 draft meeting minutes: > http://tools.ietf.org/wg/nea/minutes >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From mauricio.sanchez@hp.com Tue Aug 2 16:54:44 2011 Return-Path: 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 CED0D5E8008 for ; Tue, 2 Aug 2011 16:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.553 X-Spam-Level: X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 2tgWc-EDN3fG for ; Tue, 2 Aug 2011 16:54:44 -0700 (PDT) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2768E5E8007 for ; Tue, 2 Aug 2011 16:54:44 -0700 (PDT) Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id 20C9014266 for ; Tue, 2 Aug 2011 23:54:54 +0000 (UTC) Received: from G5W0325.americas.hpqcorp.net (16.228.8.67) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 2 Aug 2011 23:52:37 +0000 Received: from GVW0671EXC.americas.hpqcorp.net ([16.230.34.4]) by G5W0325.americas.hpqcorp.net ([16.228.8.67]) with mapi; Wed, 3 Aug 2011 00:52:37 +0100 From: "Sanchez, Mauricio (HP Networking)" To: "nea@ietf.org" Date: Wed, 3 Aug 2011 00:52:35 +0100 Thread-Topic: Consensus check on EAP-based PT Thread-Index: AcxRV8K12t9ayfNhRg2m5tY+ll6mrAADod2AAAI2byA= Message-ID: <9BC2F7926B33FE4AB10D69891D58FC1C5C787E3087@GVW0671EXC.americas.hpqcorp.net> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 23:54:44 -0000 +1. =20 My vote is also for approach #1 for same reasons as noted by Steve.=20 -Mauricio=20 -----Original Message----- From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of Steph= en Hanna Sent: Tuesday, August 02, 2011 3:54 PM To: nea@ietf.org Subject: Re: [Nea] Consensus check on EAP-based PT I prefer option 1) PT-EAP. My reasoning is that PT-EAP has been thoroughly vetted and widely implement= ed over the last five years. Also, it provides the best foundation for impo= rtant future extensions such as secure proxy, as highlighted by Stefan Wint= er's recent comments on the NEA list. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of=20 > Susan Thomson (sethomso) > Sent: Tuesday, August 02, 2011 5:04 PM > To: nea@ietf.org > Subject: [Nea] Consensus check on EAP-based PT >=20 > At IETF81 and several prior IETF meetings, as well as on the mailing=20 > list, the WG has evaluated the pros and cons of 2 architectural=20 > approaches to carrying posture within an EAP tunnel method: >=20 > - EAP method > http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-01.txt >=20 > - EAP TLV. > http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt >=20 > So far, there has been no WG consensus to adopt one architecture=20 > versus the other. (At the recent F2F meeting in Quebec City, the=20 > consensus check at the meeting showed an equal number in favor of each=20 > approach.) >=20 > This email is a final call to determine WG consensus on the L2 PT=20 > approach. >=20 > 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) >=20 > Please respond to the above question by Tues Aug 16 at 5pm PT. Please=20 > do so even if you have already expressed your opinion, either at a WG=20 > meeting or on the mailing list. The answer can be as brief as=20 > selecting option 1), 2) or 3). If you would like to add your reasons=20 > for your choice, that would be appreciated too, especially if you=20 > choose option 3). >=20 > If we have consensus on the mailing list, we will adopt the selected=20 > approach. >=20 > 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=20 > of both approaches have agreed to abide by this decision. This=20 > resolution plan was discussed at the F2F meeting at IETF81. This plan=20 > was also communicated to the list in an email on Jun 30, 2011. No=20 > objections have been received. >=20 > In either case, the individual submission corresponding to the=20 > selected approach will be adopted as a -00 NEA WG I-D, and we will=20 > proceed with the normal process of editing the document within the WG. >=20 > Thanks > Susan >=20 > ------------------ > References: > IETF81 audio session (start at approx 44 mins into session): > http://www.ietf.org/audio/ietf81/ietf81-2103-20110727-1256-pm.mp3 >=20 > IETF81 draft meeting minutes: > http://tools.ietf.org/wg/nea/minutes >=20 > _______________________________________________ > 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 From hzhou@cisco.com Tue Aug 2 17:08:13 2011 Return-Path: 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 A35ED11E80F2 for ; Tue, 2 Aug 2011 17:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 8Sl7-30Yrprf for ; Tue, 2 Aug 2011 17:08:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E15DA11E8095 for ; Tue, 2 Aug 2011 17:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=2446; q=dns/txt; s=iport; t=1312330103; x=1313539703; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=z/TyM34eFL74tsyOLt25aCzOMwqvVMsw/bcQasZ6/nM=; b=OLgQlepEpvTdPxGY0OoEKKevkDYmS446WeSniukELmb7wnZHvNn32kiZ OQohPlImE8G8lU3h0e9FZiXVevt7o4ep63FtZwmEB2o6VrAyouBU46baW 13I14pzpdZFydX0bBbOSkkw57oM+feztml3Uzj2VaAwneO9YW90+4BB1h U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEaROE6tJV2b/2dsb2JhbABBp1p3gUABAQEBAgEBAQEPAScCATEQDQEIDgRbIg4BAQQBEgkZh0oEn30BnlCGQgSSe4UQi3A X-IronPort-AV: E=Sophos;i="4.67,307,1309737600"; d="scan'208";a="9014498" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 03 Aug 2011 00:08:20 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7308Kws003991 for ; Wed, 3 Aug 2011 00:08:20 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Aug 2011 19:08:20 -0500 Received: from 10.21.106.183 ([10.21.106.183]) by XMB-RCD-202.cisco.com ([72.163.62.209]) via Exchange Front-End Server email.cisco.com ([128.107.191.114]) with Microsoft Exchange Server HTTP-DAV ; Wed, 3 Aug 2011 00:08:20 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 02 Aug 2011 20:08:17 -0400 From: Hao Zhou To: Susan Thomson , Message-ID: Thread-Topic: [Nea] Consensus check on EAP-based PT Thread-Index: AcxRV8K12t9ayfNhRg2m5tY+ll6mrAAGa8ih In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Aug 2011 00:08:20.0311 (UTC) FILETIME=[73D0A670:01CC5171] Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 00:08:13 -0000 My choice is NEA-TLV. On 8/2/11 5:04 PM, "Susan Thomson" wrote: > 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 From fyeh@us.ibm.com Tue Aug 2 19:01:08 2011 Return-Path: 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 B02D111E8081 for ; Tue, 2 Aug 2011 19:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vYtxX9VNA8Uh for ; Tue, 2 Aug 2011 19:01:08 -0700 (PDT) Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by ietfa.amsl.com (Postfix) with ESMTP id 1D50E21F8453 for ; Tue, 2 Aug 2011 19:01:07 -0700 (PDT) Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e34.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p7321Arc031886 for ; Tue, 2 Aug 2011 20:01:10 -0600 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p731xrpM176936 for ; Tue, 2 Aug 2011 19:59:53 -0600 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p731xrIE024476 for ; Tue, 2 Aug 2011 19:59:53 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.63.40.12]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p731xrVr024473 for ; Tue, 2 Aug 2011 19:59:53 -0600 In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> X-KeepSent: F3FEDFB5:F8E301CF-882578E1:000ACC3D; type=4; name=$KeepSent To: nea@ietf.org X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Frank Yeh Jr Date: Tue, 2 Aug 2011 18:59:47 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 8.0.2FP6|July 15, 2010) at 08/02/2011 19:59:52 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 02:01:08 -0000 I support method 1) PT-EAP Frank Yeh Sr. Security & Privacy Integration Architect IBM Security Services From: "Susan Thomson (sethomso)" To: Date: 08/02/2011 02:06 PM Subject: [Nea] Consensus check on EAP-based PT Sent by: nea-bounces@ietf.org 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 From aland@deployingradius.com Tue Aug 2 19:26:11 2011 Return-Path: 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 7FE6A11E80A7 for ; Tue, 2 Aug 2011 19:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 hjXC6MNjN0N9 for ; Tue, 2 Aug 2011 19:26:11 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id ECFBA11E8081 for ; Tue, 2 Aug 2011 19:26:10 -0700 (PDT) Message-ID: <4E38B1C6.6060703@deployingradius.com> Date: Tue, 02 Aug 2011 22:26:14 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Hao Zhou References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: nea@ietf.org Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 02:26:11 -0000 Hao Zhou wrote: > My choice is NEA-TLV. +1 My reason is experience has shown that TLVs work (MS SoH, etc.), and re widely deployed. Doing another EAP method is more problematic. Alan DeKok. From andreas.steffen@strongswan.org Tue Aug 2 22:55:44 2011 Return-Path: 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 7197611E80F8 for ; Tue, 2 Aug 2011 22:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] 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 wv0PoVb+iKkm for ; Tue, 2 Aug 2011 22:55:43 -0700 (PDT) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9464011E80D6 for ; Tue, 2 Aug 2011 22:55:43 -0700 (PDT) Received: from gprs51.swisscom-mobile.ch ([193.247.250.51] helo=[10.139.40.11]) by strongswan.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1QoUQd-00072Y-Px; Wed, 03 Aug 2011 07:55:40 +0200 Message-ID: <4E38E2D9.9010503@strongswan.org> Date: Wed, 03 Aug 2011 07:55:37 +0200 From: Andreas Steffen Organization: strongSwan Project User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: nea@ietf.org References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 05:55:44 -0000 Hi, my choice is option 1) PT-EAP. The advantage of using an inner EAP protocol for PT in an IKEv2 context is that within the outer TLS tunnel the initial EAP-Identity exchange, an ensuing EAP-based client authentication (e.g. EAP-MD5 or EAP-MSCHAPv2) and finally EAP-PT can be handled in a consistent way by loading the corresponding EAP plugins. Best regards Andreas On 02.08.2011 23:04, Susan Thomson (sethomso) wrote: > 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 ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== From jsalowey@cisco.com Tue Aug 2 23:50:34 2011 Return-Path: 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 74DAC5E8009 for ; Tue, 2 Aug 2011 23:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.821 X-Spam-Level: X-Spam-Status: No, score=-104.821 tagged_above=-999 required=5 tests=[AWL=-2.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 iBUJFle2KTPo for ; Tue, 2 Aug 2011 23:50:33 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A556421F8891 for ; Tue, 2 Aug 2011 23:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=4226; q=dns/txt; s=iport; t=1312354245; x=1313563845; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=NSF2ndwGXndC/PZrwf7Uj4ShksgJ2fDX2zzDlIs4FFg=; b=dAMUfr+EZEZ4LPMCbutbVtIyTZd7SMd+NgrLsN8lFXfzDteuqIoG2iA4 qQf/uHns9uFezBxJ0PEnrB4JK+DIFq38Gfkhbnko3qIaehXVlQbz+i4La dCL9xdyhyAl2cWX4rR3+dC7+qdBxZFDWNFxmm4AFhrDM0bZioyOuRzFJl 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAJ/uOE6rRDoI/2dsb2JhbABCmAWPVneBQAEBAQECAQEBAQ8BJy0HCwUHBAsOAwEDAQEoBycfAwYIBhMJGYdKBKFYAZ5OhWNfBIdaiyGFB4t9 X-IronPort-AV: E=Sophos;i="4.67,309,1309737600"; d="scan'208";a="9106927" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-9.cisco.com with ESMTP; 03 Aug 2011 06:50:43 +0000 Received: from [10.33.249.202] ([10.33.249.202]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p736ogJF002620; Wed, 3 Aug 2011 06:50:42 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Tue, 2 Aug 2011 23:50:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5A2C9B76-7BC5-48A5-B5DC-C9E99E135B29@cisco.com> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> To: Stephen Hanna X-Mailer: Apple Mail (2.1084) Cc: "nea@ietf.org" Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 06:50:34 -0000 On Aug 2, 2011, at 3:54 PM, Stephen Hanna wrote: > >=20 > I prefer option 1) PT-EAP. >=20 > 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. >=20 [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. =20 > Thanks, >=20 > Steve >=20 > >=20 >> -----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 >>=20 >> 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: >>=20 >> - EAP method >> http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-01.txt >>=20 >> - EAP TLV. >> http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt >>=20 >> 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.) >>=20 >> This email is a final call to determine WG consensus on the L2 PT >> approach. >>=20 >> 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) >>=20 >> 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). >>=20 >> If we have consensus on the mailing list, we will adopt the selected >> approach. >>=20 >> 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. >>=20 >> 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. >>=20 >> Thanks >> Susan >>=20 >> ------------------ >> References: >> IETF81 audio session (start at approx 44 mins into session): >> http://www.ietf.org/audio/ietf81/ietf81-2103-20110727-1256-pm.mp3 >>=20 >> IETF81 draft meeting minutes: >> http://tools.ietf.org/wg/nea/minutes >>=20 >> _______________________________________________ >> 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 From klaas@wierenga.net Wed Aug 3 02:53:14 2011 Return-Path: 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 C39C421F8B25 for ; Wed, 3 Aug 2011 02:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=0.998, BAYES_00=-2.599, 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 72vWrT3Iql2z for ; Wed, 3 Aug 2011 02:53:14 -0700 (PDT) Received: from out45-ams.mf.surf.net (out45-ams.mf.surf.net [145.0.1.45]) by ietfa.amsl.com (Postfix) with ESMTP id 15A0521F8A55 for ; Wed, 3 Aug 2011 02:53:12 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p739rKrm015368; Wed, 3 Aug 2011 11:53:20 +0200 Received: from 5ed00726.cm-7-1a.dynamic.ziggo.nl ([94.208.7.38] helo=[192.168.1.108]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1QoY7w-0001aL-1f; Wed, 03 Aug 2011 11:52:36 +0200 References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> Mime-Version: 1.0 (iPad Mail 8L1) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (8L1) From: Klaas Wierenga Date: Wed, 3 Aug 2011 11:53:34 +0200 To: "Susan Thomson (sethomso)" X-Antivirus: no malware found X-Bayes-Prob: 0.5 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vFfJRk8h - 22f7442f4f1b - 20110803 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.45 Cc: "" Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 09:53:14 -0000 Hi, > > 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) > I support option 2) NEA-TLV Klaas From llorenzin@juniper.net Wed Aug 3 06:15:52 2011 Return-Path: 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 02AE821F8B5F for ; Wed, 3 Aug 2011 06:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 We-3h-wOBjGJ for ; Wed, 3 Aug 2011 06:15:51 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 09B4121F8B10 for ; Wed, 3 Aug 2011 06:15:50 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTjlKEhJGZhlp7HLuUhsftnZIqL1ObQQT@postini.com; Wed, 03 Aug 2011 06:16:03 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 3 Aug 2011 06:14:19 -0700 From: Lisa Lorenzin To: "nea@ietf.org" Date: Wed, 3 Aug 2011 06:14:38 -0700 Thread-Topic: Consensus check on EAP-based PT Thread-Index: AcxRV8K12t9ayfNhRg2m5tY+ll6mrAAhp6HQ Message-ID: <189716C74BBB9C4095FE8CA503B1FC3A5528923AF3@EMBX02-HQ.jnpr.net> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:15:52 -0000 I support option 1, PT-EAP. Neither standard seems to be a clear technical leader; PT-EAP better meets the "running code" goal (more implementations) and RFC 5209 requirements (based on an existing open standard). Regards, Lisa -- Lisa Lorenzin / 919-384-7275 / llorenzin@juniper.net Principal Solutions Architect - Security & Mobility Juniper Networks / http://www.juniper.net From mlinsner@cisco.com Wed Aug 3 06:33:44 2011 Return-Path: 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 CA77A21F854D for ; Wed, 3 Aug 2011 06:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] 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 XxQrZUlzfEXH for ; Wed, 3 Aug 2011 06:33:44 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3216F21F8512 for ; Wed, 3 Aug 2011 06:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=208; q=dns/txt; s=iport; t=1312378436; x=1313588036; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=ivnEc21w1cLSwE3e+yi/Rcxv0chuo/onoZwGgAvMKds=; b=mP7/9fIufNo+0cBkQVU+8ZAKbNIS34int9Qi2ptslPAoWlQhFeSufrOH 2OlkVGGRLh0C1m09dQcbD01kbmm2bSYFwb2zJYeL6z1HHd5oa0cJipYRs 5FVmt28jnGMaGUw+sTELyAKP+l9go2v2pLSsRA6e3uR5VqSyIHy4K1ZEJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsHADhNOU6tJXG+/2dsb2JhbABCmEqPFXeBQAECAQMSAScCAU8IgR0GNagOgSMBnmqGQgSSe4UHi3k X-IronPort-AV: E=Sophos;i="4.67,310,1309737600"; d="scan'208";a="9226158" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 03 Aug 2011 13:33:56 +0000 Received: from [10.116.195.114] (rtp-mlinsner-8711.cisco.com [10.116.195.114]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p73DXp10015294 for ; Wed, 3 Aug 2011 13:33:53 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 03 Aug 2011 09:33:51 -0400 From: Marc Linsner To: Message-ID: Thread-Topic: [Nea] Consensus check on EAP-based PT In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 13:33:44 -0000 > >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) #2 -Marc Linsner- From shanna@juniper.net Wed Aug 3 07:30:36 2011 Return-Path: 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 6DE2921F8828 for ; Wed, 3 Aug 2011 07:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.59 X-Spam-Level: X-Spam-Status: No, score=-106.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 ffa3hrUVAu9O for ; Wed, 3 Aug 2011 07:30:35 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9D18821F8853 for ; Wed, 3 Aug 2011 07:30:33 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTjlblRCtZ/fCIWGTO5WF2iERnZ8bzuIi@postini.com; Wed, 03 Aug 2011 07:30:46 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 3 Aug 2011 07:28:02 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 3 Aug 2011 10:28:02 -0400 From: Stephen Hanna To: Joe Salowey Date: Wed, 3 Aug 2011 10:28:00 -0400 Thread-Topic: Protecting L2 PT when proxying Thread-Index: AcxRqeQGhMG5kgrNQ9O37CGj/GaDKAANQdAw Message-ID: References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> <5A2C9B76-7BC5-48A5-B5DC-C9E99E135B29@cisco.com> In-Reply-To: <5A2C9B76-7BC5-48A5-B5DC-C9E99E135B29@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nea@ietf.org" Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 14:30:36 -0000 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 >=20 >=20 > On Aug 2, 2011, at 3:54 PM, Stephen Hanna wrote: >=20 > > > > > > 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. >=20 > > Thanks, > > > > Steve > > > > > > > >> -----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 From mfratto@gmail.com Wed Aug 3 08:54:59 2011 Return-Path: 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 A6D6E21F8BAA for ; Wed, 3 Aug 2011 08:54:59 -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=[BAYES_00=-2.599, 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 gPK7jacxxVGQ for ; Wed, 3 Aug 2011 08:54:59 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2408D21F8BA9 for ; Wed, 3 Aug 2011 08:54:59 -0700 (PDT) Received: by iye7 with SMTP id 7so1252551iye.31 for ; Wed, 03 Aug 2011 08:55:08 -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 :content-type; bh=cv0Z7aDF0oGndBbVYXY7VvpXhmoolwrHpiyT0SRRMN4=; b=GIMKueImIu9kAG3TN8vYMbDGEDZXkbxj/EYu1gsQOs5ZCh3Vm/PSNFoUCPcY3NAT/o /lJfMep4hjZCeqTVJkISJwuZM9hxJYeuWKEEWiBa8HfjKCdoOHZyiKvvZ+n8AtqNtEDg k8rpOjgbuqkocYGHap+3GhBXvG1S9PoDhBkQo= MIME-Version: 1.0 Received: by 10.231.209.138 with SMTP id gg10mr5043832ibb.69.1312386908095; Wed, 03 Aug 2011 08:55:08 -0700 (PDT) Received: by 10.231.152.66 with HTTP; Wed, 3 Aug 2011 08:55:08 -0700 (PDT) In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> Date: Wed, 3 Aug 2011 11:55:08 -0400 Message-ID: From: Mike Fratto To: nea@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 15:54:59 -0000 Voting for 1) PT-EAP approach and strongly urge that the proposal be modified to require adequate EAP protections, re: Hanna's suggestion. From john.willis@pinfosec.com Wed Aug 3 10:28:19 2011 Return-Path: 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 8A1BD21F8784 for ; Wed, 3 Aug 2011 10:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] 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 7jO5jMdC28Rc for ; Wed, 3 Aug 2011 10:28:19 -0700 (PDT) Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with SMTP id 16D6321F84F2 for ; Wed, 3 Aug 2011 10:28:16 -0700 (PDT) Received: (qmail 11489 invoked from network); 3 Aug 2011 17:28:27 -0000 Received: from unknown (HELO gem-wbe26.prod.mesa1.secureserver.net) (64.202.189.160) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 3 Aug 2011 17:28:27 -0000 Received: (qmail 28870 invoked by uid 99); 3 Aug 2011 17:28:27 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" X-Originating-IP: 138.220.71.145 User-Agent: Web-Based Email 5.5.14 Message-Id: <20110803102826.2fb43548afc93eefed4a4d40e65e93dc.26d559a3b5.wbe@email00.secureserver.net> From: To: Nea@ietf.org Date: Wed, 03 Aug 2011 10:28:26 -0700 Mime-Version: 1.0 Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 17:28:19 -0000
 >The consensus check is to choose one of the following 3= options:
>1) PT-EAP approach
>2) NEA-TLV approach
>3) Ne= ither (please state the reason if you choose this option)

My vote is= for:
=0A
1) PT-EAP
=0A
 
 From jsalowey@cisco.com Wed Aug 3 13:55:16 2011 Return-Path: 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 5550411E807D for ; Wed, 3 Aug 2011 13:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 oVnC1w7tvI4q for ; Wed, 3 Aug 2011 13:55:15 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4734711E807C for ; Wed, 3 Aug 2011 13:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=6936; q=dns/txt; s=iport; t=1312404928; x=1313614528; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5n9ytdTvgVLjQJCDH+dGmKOjD4ZOtv/r+VNu/0IAyjQ=; b=JNutuiZmwDOuhXb+wlpvdbuFHqB8dfQmrtZSuUUWyjA3SXAuV1v9F7jK htVw26lMkiYMHoQUBy3+QDzw5jyRTPIKjJYo7QmkzYr1+3PkJREcn5m+k S6NOBfZ8qQeitaqNKF1XUwQoGkjuBy5uiSIaE/4DlAFoJJGGrcgO6Am7t k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusAAAe1OU6rRDoH/2dsb2JhbABCmAePWneBQAEBAQECAQEBAQ8BJy0HCwUHBAsOAwEDAQEBJwcnHwMGCAYTCRmHSgSiJwGeaoVjXwSHWoshhQeLfQ X-IronPort-AV: E=Sophos;i="4.67,312,1309737600"; d="scan'208";a="9409815" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 03 Aug 2011 20:55:27 +0000 Received: from [10.33.249.202] ([10.33.249.202]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p73KtQTB021402; Wed, 3 Aug 2011 20:55:26 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Wed, 3 Aug 2011 13:55:20 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> <5A2C9B76-7BC5-48A5-B5DC-C9E99E135B29@cisco.com> To: Stephen Hanna X-Mailer: Apple Mail (2.1084) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:55:16 -0000 On Aug 3, 2011, at 7:28 AM, Stephen Hanna wrote: > Joe, >=20 > I have changed the subject line since we're pursuing a > different topic now. >=20 > 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. >=20 > 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. =20 > 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. >=20 [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. =20 > Thanks, >=20 > Steve >=20 >> -----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 >>=20 >>=20 >> On Aug 2, 2011, at 3:54 PM, Stephen Hanna wrote: >>=20 >>> >>>=20 >>> I prefer option 1) PT-EAP. >>>=20 >>> 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. >>>=20 >> [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. >>=20 >>> Thanks, >>>=20 >>> Steve >>>=20 >>> >>>=20 >>>> -----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 >>>>=20 >>>> 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: >>>>=20 >>>> - EAP method >>>> http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-01.txt >>>>=20 >>>> - EAP TLV. >>>> http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt >>>>=20 >>>> 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.) >>>>=20 >>>> This email is a final call to determine WG consensus on the L2 PT >>>> approach. >>>>=20 >>>> 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) >>>>=20 >>>> 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). >>>>=20 >>>> If we have consensus on the mailing list, we will adopt the = selected >>>> approach. >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Thanks >>>> Susan >>>>=20 >>>> ------------------ >>>> References: >>>> IETF81 audio session (start at approx 44 mins into session): >>>> http://www.ietf.org/audio/ietf81/ietf81-2103-20110727-1256-pm.mp3 >>>>=20 >>>> IETF81 draft meeting minutes: >>>> http://tools.ietf.org/wg/nea/minutes >>>>=20 >>>> _______________________________________________ >>>> 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 >=20 From jsalowey@cisco.com Wed Aug 3 13:57:01 2011 Return-Path: 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 4DE7211E8092 for ; Wed, 3 Aug 2011 13:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.417 X-Spam-Level: X-Spam-Status: No, score=-104.417 tagged_above=-999 required=5 tests=[AWL=-1.818, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 HXsRfemUBSIQ for ; Wed, 3 Aug 2011 13:57:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7301911E807C for ; Wed, 3 Aug 2011 13:57:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=3615; q=dns/txt; s=iport; t=1312405033; x=1313614633; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Pvft8cCs0eTp+3Lz+zN9wSk0G2Z4Oxyal92o03haZ5I=; b=jyk2LPfcTPhua6KtzwDlecEkZgTKwYAf3loW4uO/bWHRXmZgxUCPMlt8 yezcvkYtD5o8FT4/W2l2BcI4Csdhzl5sDlNES7IFPrtDIZH2EXMrBxARA LTPEfQ9lqSrjcF5kbNQ1Ab6lP997cPf1yr34akqU9hiExRcq4+yjOxMWd s=; X-IronPort-AV: E=Sophos;i="4.67,312,1309737600"; d="scan'208";a="9409283" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 03 Aug 2011 20:57:13 +0000 Received: from [10.33.249.202] ([10.33.249.202]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p73KvCrh023577; Wed, 3 Aug 2011 20:57:12 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> Date: Wed, 3 Aug 2011 13:57:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <694CBCE8-01AA-4350-8D9C-6A6DE9F3C35B@cisco.com> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> To: Susan Thomson (sethomso) X-Mailer: Apple Mail (2.1084) Cc: nea@ietf.org Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 20:57:01 -0000 I prefer the TLV based approach. The EAP based approach creates an = anomalous EAP method whose behavior must be accommodated for in EAP and = AAA implementations as a special case. While much of the complexity = can be hidden within a tunnel method, the tunnel method itself will need = to deal with the oddities resulting from trying to fit a method whose = goal is not authentication into an authentication framework. It = addition, it seems there is an intention to expose PT-EAP outside the = tunnel method, which exposes the special case treatment outside of the = tunnel method. The fact that implementations have worked around some of = these issues does not justify creating a standard around these = exceptions to the architecture. =20 If we do go down the path of PT-EAP then the exceptions to the EAP = framework need to be documented, the method should only be allowed = within a tunnel method and I think there should be a recommendation = against creating more special case EAP methods for other purposes. The = later should also be part of the EAP applicability statement update.=20 Cheers, Joe On Aug 2, 2011, at 2:04 PM, Susan Thomson (sethomso) wrote: > 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:=20 >=20 > - EAP method=20 > http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-01.txt >=20 > - EAP TLV. > http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt >=20 > 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.) >=20 > This email is a final call to determine WG consensus on the L2 PT > approach.=20 >=20 > 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) >=20 > 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). >=20 > If we have consensus on the mailing list, we will adopt the selected > approach. >=20 > 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. >=20 > 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. >=20 > Thanks > Susan >=20 > ------------------ > References: > IETF81 audio session (start at approx 44 mins into session):=20 > http://www.ietf.org/audio/ietf81/ietf81-2103-20110727-1256-pm.mp3 >=20 > IETF81 draft meeting minutes: > http://tools.ietf.org/wg/nea/minutes >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From j@w1.fi Wed Aug 3 14:27:33 2011 Return-Path: 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 1E46E11E8099 for ; Wed, 3 Aug 2011 14:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.046 X-Spam-Level: X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] 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 phJr2s0rGy7o for ; Wed, 3 Aug 2011 14:27:32 -0700 (PDT) Received: from jmalinen.user.openhosting.com (w1.fi [128.177.27.249]) by ietfa.amsl.com (Postfix) with ESMTP id 215BF11E807C for ; Wed, 3 Aug 2011 14:27:31 -0700 (PDT) Received: from jm (a88-112-98-2.elisa-laajakaista.fi [88.112.98.2]) (authenticated bits=0) by jmalinen.user.openhosting.com (8.13.8/8.13.8) with ESMTP id p73LRJ04023324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Aug 2011 17:27:21 -0400 Received: by jm (sSMTP sendmail emulation); Thu, 04 Aug 2011 00:27:19 +0300 Date: Thu, 4 Aug 2011 00:27:19 +0300 From: Jouni Malinen To: "Susan Thomson (sethomso)" Message-ID: <20110803212719.GA30882@jm.kir.nu> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: nea@ietf.org Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2011 21:27:33 -0000 On Tue, Aug 02, 2011 at 04:04:25PM -0500, Susan Thomson (sethomso) wrote: > 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) My preference is 1) PT-EAP approach Based on my experience working with both EAP-based and TLV-based extensions for EAP-{TTLS,PEAP,FAST}, the EAP-based design felt cleaner and simpler to implement and maintain. -- Jouni Malinen PGP id EFC895FA From shanna@juniper.net Wed Aug 3 17:47:35 2011 Return-Path: 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 56F6611E80C2 for ; Wed, 3 Aug 2011 17:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 WMMxSo4Wyg6C for ; Wed, 3 Aug 2011 17:47:34 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 5804F11E80B7 for ; Wed, 3 Aug 2011 17:47:33 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTjnsMjNFFahHMSf5ViOpgclrQGJj4w6I@postini.com; Wed, 03 Aug 2011 17:47:47 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 3 Aug 2011 17:47:46 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 3 Aug 2011 20:47:45 -0400 From: Stephen Hanna To: Joe Salowey Date: Wed, 3 Aug 2011 20:47:43 -0400 Thread-Topic: Protecting L2 PT when proxying Thread-Index: AcxSH65cYWZlQZqFTuy3p7NaqTy88QAACggQ Message-ID: References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> <5A2C9B76-7BC5-48A5-B5DC-C9E99E135B29@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 00:47:35 -0000 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. >=20 > [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: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: > >> > >>> > >>> > >>> 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 > >>> > >>> > >>> > >>>> -----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 > > From ncamwing@cisco.com Wed Aug 3 18:26:08 2011 Return-Path: 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 2C05821F8A96 for ; Wed, 3 Aug 2011 18:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 Z7jtmOMzRdqR for ; Wed, 3 Aug 2011 18:26:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id E663121F8A95 for ; Wed, 3 Aug 2011 18:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ncamwing@cisco.com; l=10034; q=dns/txt; s=iport; t=1312421180; x=1313630780; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=SdEtA9ZBUmIN6+7JU1jURTlryn1Rh5ORrp/WJYvwNCg=; b=InrUdZOAUWkTaZeJw+PAwJIjfkhaTamHTi3XJOjpwPIfVBfMgEkKfbsO lgmmyNNzUL0KtDY4n9XQ+3bSscsf081OO9iRXdqtGnF7FJXYUQihlon6X B+CgeLQNI/WDdSmWfbmF/AvgAXF08oyRyaU9OptR8w/HkiNlWyeNi/BVh Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAAr1OU6rRDoH/2dsb2JhbAA5CYJNnHGHN213gUABAQEBAgEBAQEPASoxEA0BCA4EWyIOAQEEARIJGYdKBKF0AZ5ygyWDHQSHWoshhRCLdA X-IronPort-AV: E=Sophos;i="4.67,313,1309737600"; d="scan'208,217";a="9487370" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-7.cisco.com with ESMTP; 04 Aug 2011 01:26:18 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p741QIXx015394 for ; Thu, 4 Aug 2011 01:26:18 GMT Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 18:26:18 -0700 Received: from 10.21.79.229 ([10.21.79.229]) by xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) with Microsoft Exchange Server HTTP-DAV ; Thu, 4 Aug 2011 01:26:17 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 03 Aug 2011 18:26:16 -0700 From: Nancy Cam-Winget To: Susan Thomson , Message-ID: Thread-Topic: [Nea] Consensus check on EAP-based PT Thread-Index: AcxRV8K12t9ayfNhRg2m5tY+ll6mrAA7b5yt In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3395240777_65247" X-OriginalArrivalTime: 04 Aug 2011 01:26:18.0349 (UTC) FILETIME=[828E59D0:01CC5245] Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 01:26:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3395240777_65247 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I prefer the EAP-TLV approach. While there may be implementations that are close to the EAP-PT proposal, there are also similar implementations of the EAP-TLV. Several EAP-PT issues and concerns were raised that for me, outweigh the "benefits of already having code": - the goal for NEA is to define a transport for data. EAP is designed and defined to be an authentication framework. To "only carry data", issues for how the design must now accommodate the "no authentication" must now be compensated for... For instance: how does the state machine know that the intent is for it to carry NEA data only and not authentication? The two main issues of violations for using an authentication framework (EAP) for not doing authentication is in the generation of an identity and the creation of keys. - code and configuration updates are going to be needed regardless of whether we adopt EAP-PT or EAP-TLV. While it may be perceived to "be simpler" as some vendors allow for ease of adding EAP methods....these interfaces were intended to be defined for adding new authentication methods, not "methods that only carry data". - the above raises one of my security concerns that if we were to allow for "lets just add another EAP method", there is the danger that EAP-PT can be used as a standalone method which we have discussed as being insecure. As Joe succinctly states, while we can make special cases for EAP-PT....but more importantly, I think we are setting a bad precedence in defining a "non authenticating" EAP method and opening the door for defining other things as EAP methods too..... Nancy. On 8/2/11 2:04 PM, "Susan Thomson" wrote: > 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 > --B_3395240777_65247 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Nea] Consensus check on EAP-based PT I prefer the EAP-TLV approach.

While there may be implementations that are close to the EAP-PT proposal,  there are also similar implementations of the EAP-TLV.

Several EAP-PT issues and concerns were raised that for me, outweigh
 the "benefits of already having code":
 - the goal for NEA is to define a transport for data.  EAP is de= signed
 and defined to be an authentication framework.  To "only ca= rry data",
 issues for how the design must now accommodate the "no authentic= ation"
 must now be compensated for...  For instance: how does the state= machine
 know that the intent is for it to carry NEA data only and not authent= ication?
 The two main issues of violations for using an authentication framewo= rk (EAP)
 for not doing authentication is in the generation of an identity and = the
 creation of keys.

 - code and configuration updates are going to be needed regardless of=
 whether we adopt EAP-PT or EAP-TLV.  While it may be perceived t= o "be simpler" as some vendors allow for ease of adding EAP method= s....these
 interfaces were intended to be defined for adding new authentication<= BR>  methods, not "methods that only carry data".  

 - the above raises one of my security concerns that if we were to all= ow
 for "lets just add another EAP method", there is the danger= that EAP-PT
 can be used as a standalone method which we have discussed as being  insecure.  As Joe succinctly states, while we can make special c= ases
 for EAP-PT....but more importantly, I think we are setting a bad prec= edence
 in defining a "non authenticating" EAP method and opening t= he door for
 defining other things as EAP methods too.....

   Nancy.


On 8/2/11 2:04 PM, "Susan Thomson" <sethomso@cisco.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>At IETF81 and several prior IETF meetings, as we= ll 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/ma= ilman/listinfo/nea

--B_3395240777_65247-- From jsalowey@cisco.com Wed Aug 3 22:20:58 2011 Return-Path: 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 A961711E80E2 for ; Wed, 3 Aug 2011 22:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.266 X-Spam-Level: X-Spam-Status: No, score=-104.266 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 WeufwMfNjuSv for ; Wed, 3 Aug 2011 22:20:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC0511E80E1 for ; Wed, 3 Aug 2011 22:20:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=9449; q=dns/txt; s=iport; t=1312435271; x=1313644871; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=GlFASLjI6pV0xxLzs9U81rCA9+yE4e9lIV+/GN5WEUc=; b=dFdEQS6YV2kLGKzQgm0fIJbBk05RZdXT7z4p1WB+a635TV/oQwE3Plah 0uRzukHnY/iCGdkQm0n8yh2kjgaDa/smzHjG0smiGP2wT4YM22lfbRoq+ cp3gtOvejBsxra1NXTp1T1xptiEL/jrOUigYM1mQRJ1gBGBG+vmllM8ne 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0AAH0rOk6rRDoG/2dsb2JhbABCmAmPWneBQAEBAQECAQEBAQ8BJy0HCwUHBAsOAwEDAQEBJwcnHwMGCAYTCRmHSgSiSAGefIVjXwSHWoshhQeLfQ X-IronPort-AV: E=Sophos;i="4.67,315,1309737600"; d="scan'208";a="9525153" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-5.cisco.com with ESMTP; 04 Aug 2011 05:21:10 +0000 Received: from [10.0.0.7] (sjc-vpn3-327.cisco.com [10.21.65.71]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p745L9Sh020078; Thu, 4 Aug 2011 05:21:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Wed, 3 Aug 2011 22:20:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9CF77382-FF31-4ADA-9A56-64A23380FABF@cisco.com> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> <5A2C9B76-7BC5-48A5-B5DC-C9E99E135B29@cisco.com> To: Stephen Hanna X-Mailer: Apple Mail (2.1084) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 05:20:58 -0000 On Aug 3, 2011, at 5:47 PM, Stephen Hanna wrote: > My comments are inline below. >=20 > 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. >>>=20 >>> The same requirements should apply to proxying PT beyond >>> the end of the EAP tunnel method. >>=20 >> [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. >=20 > 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. >=20 >>> 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. >>>=20 >> [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. >=20 > 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. =20 > 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. >=20 [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. =20 > Thanks, >=20 > Steve >=20 >>>> -----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 >>>>=20 >>>>=20 >>>> On Aug 2, 2011, at 3:54 PM, Stephen Hanna wrote: >>>>=20 >>>>> >>>>>=20 >>>>> I prefer option 1) PT-EAP. >>>>>=20 >>>>> 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. >>>>>=20 >>>> [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. >>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Steve >>>>>=20 >>>>> >>>>>=20 >>>>>> -----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 >>>>>>=20 >>>>>> 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: >>>>>>=20 >>>>>> - EAP method >>>>>> http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-01.txt >>>>>>=20 >>>>>> - EAP TLV. >>>>>> http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv- >> 03.txt >>>>>>=20 >>>>>> 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.) >>>>>>=20 >>>>>> This email is a final call to determine WG consensus on the L2 PT >>>>>> approach. >>>>>>=20 >>>>>> 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) >>>>>>=20 >>>>>> 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). >>>>>>=20 >>>>>> If we have consensus on the mailing list, we will adopt the >> selected >>>>>> approach. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Thanks >>>>>> Susan >>>>>>=20 >>>>>> ------------------ >>>>>> References: >>>>>> IETF81 audio session (start at approx 44 mins into session): >>>>>> http://www.ietf.org/audio/ietf81/ietf81-2103-20110727-1256-pm.mp3 >>>>>>=20 >>>>>> IETF81 draft meeting minutes: >>>>>> http://tools.ietf.org/wg/nea/minutes >>>>>>=20 >>>>>> _______________________________________________ >>>>>> 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 >>>=20 >=20 From latze@angry-red-pla.net Wed Aug 3 23:35:43 2011 Return-Path: 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 E754C11E80F5 for ; Wed, 3 Aug 2011 23:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FROM_EXCESS_BASE64=1.456, HTML_MESSAGE=0.001, SARE_SUB_ENC_UTF8=0.152] 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 rw6xbo0lYt7w for ; Wed, 3 Aug 2011 23:35:43 -0700 (PDT) Received: from thuvia.angry-red-pla.net (thuvia.angry-red-pla.net [83.169.33.217]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3F811E80F2 for ; Wed, 3 Aug 2011 23:35:42 -0700 (PDT) Received: from gprs29.swisscom-mobile.ch ([193.247.250.29] helo=[10.131.192.74]) by thuvia.angry-red-pla.net with esmtpsa (TLS1.0:RSA_ARCFOUR_MD5:16) (Exim 4.69) (envelope-from ) id 1QorX7-0005JS-KZ; Thu, 04 Aug 2011 08:35:55 +0200 To: "=?utf-8?B?U3VzYW4gVGhvbXNvbiAoc2V0aG9tc28p?=" , nea@ietf.org From: "=?utf-8?B?bGF0emVAYW5ncnktcmVkLXBsYS5uZXQ=?=" Date: Thu, 04 Aug 2011 08:35:52 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7_1312439752251" Message-Id: Subject: Re: [Nea] =?utf-8?q?Consensus_check_on_EAP-based_PT?= X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 06:35:44 -0000 ------=_Part_7_1312439752251 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline UFQtRUFQCgoKCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0KRnJvbTogIlN1c2FuIFRob21zb24g KHNldGhvbXNvKSIgPHNldGhvbXNvQGNpc2NvLmNvbT4KVG86IDxuZWFAaWV0Zi5vcmc+ClN1Ympl Y3Q6IFtOZWFdIENvbnNlbnN1cyBjaGVjayBvbiBFQVAtYmFzZWQgUFQKRGF0ZTogVHVlLCBBdWcg MiwgMjAxMSAxMTowNCBwbQoKCkF0IElFVEY4MSBhbmQgc2V2ZXJhbCBwcmlvciBJRVRGIG1lZXRp bmdzLCBhcyB3ZWxsIGFzIG9uIHRoZSBtYWlsaW5nCmxpc3QsIHRoZSBXRyBoYXMgZXZhbHVhdGVk IHRoZSBwcm9zIGFuZCBjb25zIG9mIDIgYXJjaGl0ZWN0dXJhbAphcHByb2FjaGVzIHRvIGNhcnJ5 aW5nIHBvc3R1cmUgd2l0aGluIGFuIEVBUCB0dW5uZWwgbWV0aG9kOiAKCi0gRUFQIG1ldGhvZCAK aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaGFubmEtbmVhLXB0LWVh cC0wMS50eHQKCi0gRUFQIFRMVi4KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtY2FtLXdpbmdldC1lYXAtdGx2LTAzLnR4dAoKU28gZmFyLCB0aGVyZSBoYXMgYmVlbiBu byBXRyBjb25zZW5zdXMgdG8gYWRvcHQgb25lIGFyY2hpdGVjdHVyZSB2ZXJzdXMKdGhlIG90aGVy LiAoQXQgdGhlIHJlY2VudCBGMkYgbWVldGluZyBpbiBRdWViZWMgQ2l0eSwgdGhlIGNvbnNlbnN1 cwpjaGVjayBhdCB0aGUgbWVldGluZyBzaG93ZWQgYW4gZXF1YWwgbnVtYmVyIGluIGZhdm9yIG9m IGVhY2ggYXBwcm9hY2guKQoKVGhpcyBlbWFpbCBpcyBhIGZpbmFsIGNhbGwgdG8gZGV0ZXJtaW5l IFdHIGNvbnNlbnN1cyBvbiB0aGUgTDIgUFQKYXBwcm9hY2guIAoKVGhlIGNvbnNlbnN1cyBjaGVj ayBpcyB0byBjaG9vc2Ugb25lIG9mIHRoZSBmb2xsb3dpbmcgMyBvcHRpb25zOgoxKSBQVC1FQVAg YXBwcm9hY2gKMikgTkVBLVRMViBhcHByb2FjaAozKSBOZWl0aGVyIChwbGVhc2Ugc3RhdGUgdGhl IHJlYXNvbiBpZiB5b3UgY2hvb3NlIHRoaXMgb3B0aW9uKQoKUGxlYXNlIHJlc3BvbmQgdG8gdGhl IGFib3ZlIHF1ZXN0aW9uIGJ5IFR1ZXMgQXVnIDE2IGF0IDVwbSBQVC4gUGxlYXNlIGRvCnNvIGV2 ZW4gaWYgeW91IGhhdmUgYWxyZWFkeSBleHByZXNzZWQgeW91ciBvcGluaW9uLCBlaXRoZXIgYXQg YSBXRwptZWV0aW5nIG9yIG9uIHRoZSBtYWlsaW5nIGxpc3QuIFRoZSBhbnN3ZXIgY2FuIGJlIGFz IGJyaWVmIGFzIHNlbGVjdGluZwpvcHRpb24gMSksIDIpIG9yIDMpLiBJZiB5b3Ugd291bGQgbGlr ZSB0byBhZGQgeW91ciByZWFzb25zIGZvciB5b3VyCmNob2ljZSwgdGhhdCB3b3VsZCBiZSBhcHBy ZWNpYXRlZCB0b28sIGVzcGVjaWFsbHkgaWYgeW91IGNob29zZSBvcHRpb24KMykuCgpJZiB3ZSBo YXZlIGNvbnNlbnN1cyBvbiB0aGUgbWFpbGluZyBsaXN0LCB3ZSB3aWxsIGFkb3B0IHRoZSBzZWxl Y3RlZAphcHByb2FjaC4KCklmIHdlIHN0aWxsIGRvIG5vdCBoYXZlIGNvbnNlbnN1cywgdGhlIFdH IGNoYWlycyBhbmQgQUQgKFN0ZXBoZW4KRmFycmVsbCkgaGF2ZSBhZ3JlZWQgdGhhdCB0aGUgQUQg d2lsbCBtYWtlIGEgZGVjaXNpb24uIFRoZSBwcm9wb25lbnRzIG9mCmJvdGggYXBwcm9hY2hlcyBo YXZlIGFncmVlZCB0byBhYmlkZSBieSB0aGlzIGRlY2lzaW9uLiBUaGlzIHJlc29sdXRpb24KcGxh biB3YXMgZGlzY3Vzc2VkIGF0IHRoZSBGMkYgbWVldGluZyBhdCBJRVRGODEuIFRoaXMgcGxhbiB3 YXMgYWxzbwpjb21tdW5pY2F0ZWQgdG8gdGhlIGxpc3QgaW4gYW4gZW1haWwgb24gSnVuIDMwLCAy MDExLiBObyBvYmplY3Rpb25zIGhhdmUKYmVlbiByZWNlaXZlZC4KCkluIGVpdGhlciBjYXNlLCB0 aGUgaW5kaXZpZHVhbCBzdWJtaXNzaW9uIGNvcnJlc3BvbmRpbmcgdG8gdGhlIHNlbGVjdGVkCmFw cHJvYWNoIHdpbGwgYmUgYWRvcHRlZCBhcyBhIC0wMCBORUEgV0cgSS1ELCBhbmQgd2Ugd2lsbCBw cm9jZWVkIHdpdGgKdGhlIG5vcm1hbCBwcm9jZXNzIG9mIGVkaXRpbmcgdGhlIGRvY3VtZW50IHdp dGhpbiB0aGUgV0cuCgpUaGFua3MKU3VzYW4KCi0tLS0tLS0tLS0tLS0tLS0tLQpSZWZlcmVuY2Vz OgpJRVRGODEgYXVkaW8gc2Vzc2lvbiAoc3RhcnQgYXQgYXBwcm94IDQ0IG1pbnMgaW50byBzZXNz aW9uKTogCmh0dHA6Ly93d3cuaWV0Zi5vcmcvYXVkaW8vaWV0ZjgxL2lldGY4MS0yMTAzLTIwMTEw NzI3LTEyNTYtcG0ubXAzCgpJRVRGODEgZHJhZnQgbWVldGluZyBtaW51dGVzOgpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvd2cvbmVhL21pbnV0ZXMKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fCk5lYSBtYWlsaW5nIGxpc3QKTmVhQGlldGYub3JnCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmVhCg== ------=_Part_7_1312439752251 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 Content-Disposition: inline UFQtRUFQPGJyPjxicj48YnI+PGJyPi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS08YnI+RnJvbTog JnF1b3Q7U3VzYW4gVGhvbXNvbiAoc2V0aG9tc28pJnF1b3Q7ICZsdDtzZXRob21zb0BjaXNjby5j b20mZ3Q7PGJyPlRvOiAmbHQ7bmVhQGlldGYub3JnJmd0Ozxicj5TdWJqZWN0OiBbTmVhXSBDb25z ZW5zdXMgY2hlY2sgb24gRUFQLWJhc2VkIFBUPGJyPkRhdGU6IFR1ZSwgQXVnIDIsIDIwMTEgMTE6 MDQgcG08YnI+PGJyPjxicj5BdCBJRVRGODEgYW5kIHNldmVyYWwgcHJpb3IgSUVURiBtZWV0aW5n cywgYXMgd2VsbCBhcyBvbiB0aGUgbWFpbGluZzxicj5saXN0LCB0aGUgV0cgaGFzIGV2YWx1YXRl ZCB0aGUgcHJvcyBhbmQgY29ucyBvZiAyIGFyY2hpdGVjdHVyYWw8YnI+YXBwcm9hY2hlcyB0byBj YXJyeWluZyBwb3N0dXJlIHdpdGhpbiBhbiBFQVAgdHVubmVsIG1ldGhvZDogPGJyPjxicj4tIEVB UCBtZXRob2QgPGJyPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWhh bm5hLW5lYS1wdC1lYXAtMDEudHh0PGJyPjxicj4tIEVBUCBUTFYuPGJyPmh0dHA6Ly93d3cuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWNhbS13aW5nZXQtZWFwLXRsdi0wMy50eHQ8YnI+ PGJyPlNvIGZhciwgdGhlcmUgaGFzIGJlZW4gbm8gV0cgY29uc2Vuc3VzIHRvIGFkb3B0IG9uZSBh cmNoaXRlY3R1cmUgdmVyc3VzPGJyPnRoZSBvdGhlci4gKEF0IHRoZSByZWNlbnQgRjJGIG1lZXRp bmcgaW4gUXVlYmVjIENpdHksIHRoZSBjb25zZW5zdXM8YnI+Y2hlY2sgYXQgdGhlIG1lZXRpbmcg c2hvd2VkIGFuIGVxdWFsIG51bWJlciBpbiBmYXZvciBvZiBlYWNoIGFwcHJvYWNoLik8YnI+PGJy PlRoaXMgZW1haWwgaXMgYSBmaW5hbCBjYWxsIHRvIGRldGVybWluZSBXRyBjb25zZW5zdXMgb24g dGhlIEwyIFBUPGJyPmFwcHJvYWNoLiA8YnI+PGJyPlRoZSBjb25zZW5zdXMgY2hlY2sgaXMgdG8g Y2hvb3NlIG9uZSBvZiB0aGUgZm9sbG93aW5nIDMgb3B0aW9uczo8YnI+MSkgUFQtRUFQIGFwcHJv YWNoPGJyPjIpIE5FQS1UTFYgYXBwcm9hY2g8YnI+MykgTmVpdGhlciAocGxlYXNlIHN0YXRlIHRo ZSByZWFzb24gaWYgeW91IGNob29zZSB0aGlzIG9wdGlvbik8YnI+PGJyPlBsZWFzZSByZXNwb25k IHRvIHRoZSBhYm92ZSBxdWVzdGlvbiBieSBUdWVzIEF1ZyAxNiBhdCA1cG0gUFQuIFBsZWFzZSBk bzxicj5zbyBldmVuIGlmIHlvdSBoYXZlIGFscmVhZHkgZXhwcmVzc2VkIHlvdXIgb3Bpbmlvbiwg ZWl0aGVyIGF0IGEgV0c8YnI+bWVldGluZyBvciBvbiB0aGUgbWFpbGluZyBsaXN0LiBUaGUgYW5z d2VyIGNhbiBiZSBhcyBicmllZiBhcyBzZWxlY3Rpbmc8YnI+b3B0aW9uIDEpLCAyKSBvciAzKS4g SWYgeW91IHdvdWxkIGxpa2UgdG8gYWRkIHlvdXIgcmVhc29ucyBmb3IgeW91cjxicj5jaG9pY2Us IHRoYXQgd291bGQgYmUgYXBwcmVjaWF0ZWQgdG9vLCBlc3BlY2lhbGx5IGlmIHlvdSBjaG9vc2Ug b3B0aW9uPGJyPjMpLjxicj48YnI+SWYgd2UgaGF2ZSBjb25zZW5zdXMgb24gdGhlIG1haWxpbmcg bGlzdCwgd2Ugd2lsbCBhZG9wdCB0aGUgc2VsZWN0ZWQ8YnI+YXBwcm9hY2guPGJyPjxicj5JZiB3 ZSBzdGlsbCBkbyBub3QgaGF2ZSBjb25zZW5zdXMsIHRoZSBXRyBjaGFpcnMgYW5kIEFEIChTdGVw aGVuPGJyPkZhcnJlbGwpIGhhdmUgYWdyZWVkIHRoYXQgdGhlIEFEIHdpbGwgbWFrZSBhIGRlY2lz aW9uLiBUaGUgcHJvcG9uZW50cyBvZjxicj5ib3RoIGFwcHJvYWNoZXMgaGF2ZSBhZ3JlZWQgdG8g YWJpZGUgYnkgdGhpcyBkZWNpc2lvbi4gVGhpcyByZXNvbHV0aW9uPGJyPnBsYW4gd2FzIGRpc2N1 c3NlZCBhdCB0aGUgRjJGIG1lZXRpbmcgYXQgSUVURjgxLiBUaGlzIHBsYW4gd2FzIGFsc288YnI+ Y29tbXVuaWNhdGVkIHRvIHRoZSBsaXN0IGluIGFuIGVtYWlsIG9uIEp1biAzMCwgMjAxMS4gTm8g b2JqZWN0aW9ucyBoYXZlPGJyPmJlZW4gcmVjZWl2ZWQuPGJyPjxicj5JbiBlaXRoZXIgY2FzZSwg dGhlIGluZGl2aWR1YWwgc3VibWlzc2lvbiBjb3JyZXNwb25kaW5nIHRvIHRoZSBzZWxlY3RlZDxi cj5hcHByb2FjaCB3aWxsIGJlIGFkb3B0ZWQgYXMgYSAtMDAgTkVBIFdHIEktRCwgYW5kIHdlIHdp bGwgcHJvY2VlZCB3aXRoPGJyPnRoZSBub3JtYWwgcHJvY2VzcyBvZiBlZGl0aW5nIHRoZSBkb2N1 bWVudCB3aXRoaW4gdGhlIFdHLjxicj48YnI+VGhhbmtzPGJyPlN1c2FuPGJyPjxicj4tLS0tLS0t LS0tLS0tLS0tLS08YnI+UmVmZXJlbmNlczo8YnI+SUVURjgxIGF1ZGlvIHNlc3Npb24gKHN0YXJ0 IGF0IGFwcHJveCA0NCBtaW5zIGludG8gc2Vzc2lvbik6IDxicj5odHRwOi8vd3d3LmlldGYub3Jn L2F1ZGlvL2lldGY4MS9pZXRmODEtMjEwMy0yMDExMDcyNy0xMjU2LXBtLm1wMzxicj48YnI+SUVU RjgxIGRyYWZ0IG1lZXRpbmcgbWludXRlczo8YnI+aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL25l YS9taW51dGVzPGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj5OZWEgbWFpbGluZyBsaXN0PGJyPk5lYUBpZXRmLm9yZzxicj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25lYTxicj4= ------=_Part_7_1312439752251-- From shanna@juniper.net Fri Aug 5 14:38:21 2011 Return-Path: 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 87ED321F8B4E for ; Fri, 5 Aug 2011 14:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Q5QocUfv2nC7 for ; Fri, 5 Aug 2011 14:38:20 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6393B21F8B4F for ; Fri, 5 Aug 2011 14:38:19 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTjxi3Wpc0Iss+99/rGJ1CMTX5QM2TKt6@postini.com; Fri, 05 Aug 2011 14:38:38 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 5 Aug 2011 14:38:06 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 5 Aug 2011 17:38:06 -0400 From: Stephen Hanna To: Joe Salowey Date: Fri, 5 Aug 2011 17:38:03 -0400 Thread-Topic: Protecting L2 PT when proxying Thread-Index: AcxSZlXqugenrS2pSd6JvkJ80hHrEAAR1TyQ Message-ID: References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> <5A2C9B76-7BC5-48A5-B5DC-C9E99E135B29@cisco.com> <9CF77382-FF31-4ADA-9A56-64A23380FABF@cisco.com> In-Reply-To: <9CF77382-FF31-4ADA-9A56-64A23380FABF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 21:38:21 -0000 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 >=20 >=20 > On Aug 3, 2011, at 5:47 PM, Stephen Hanna wrote: >=20 > > 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. >=20 > [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. >=20 > > 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. > > >=20 > [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. >=20 > > 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: > >>>> > >>>>> > >>>>> > >>>>> 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 > >>>>> > >>>>> > >>>>> > >>>>>> -----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 > >>> > > From mfratto@gmail.com Sat Aug 6 07:21:23 2011 Return-Path: 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 ; 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 ; 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 ; Sat, 6 Aug 2011 07:21:21 -0700 (PDT) Received: by iye1 with SMTP id 1so5213527iye.27 for ; 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: References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> <5A2C9B76-7BC5-48A5-B5DC-C9E99E135B29@cisco.com> <9CF77382-FF31-4ADA-9A56-64A23380FABF@cisco.com> Date: Sat, 6 Aug 2011 10:21:40 -0400 Message-ID: From: Mike Fratto To: Stephen Hanna Content-Type: multipart/alternative; boundary=000e0cdfc8bec00b6e04a9d6eef6 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 14:21:23 -0000 --000e0cdfc8bec00b6e04a9d6eef6 Content-Type: text/plain; charset=ISO-8859-1 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" 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: >> >>>> >> >>>>> >> >>>>> >> >>>>> 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 >> >>>>> >> >>>>> >> >>>>> >> >>>>>> -----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 --000e0cdfc8bec00b6e04a9d6eef6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

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-interop= erable implementations.

On Aug 5, 2011 5:38 PM, "Stephen Hanna"= ; <shanna@juniper.net> wrot= e:
> Joe,
>
> Neither proposed PT m= ethod includes confidentiality or
> integrity protection. Both are dependent on an enclosing
> tunne= l to provide those protections. Everyone has agreed
> that we will in= clude explicit language in the final NEA
> L2 PT specification, prohi= biting sending L2 PT messages
> without proper security protections. The risks and
> countermeas= ures here are the same for the two proposals.
>
> You may beli= eve that the risks are greater with an EAP
> method but many develope= rs have proxied posture TLVs
> over RADIUS without protection. The risk is the same
> for both = proposals.
>
> I'm fine with prohibiting the use of whatev= er 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 ou= r 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 addre= ss your
> concern about defining a new EAP method that's not
> safe fo= r use outside a tunnel. It would even make
> PT-EAP a true authentica= tion method, although the
> identity established would only be "= one of the
> endpoints for TLS tunnel X."
>
> Thanks,
> > Steve
>
>> -----Original Message-----
>> Fro= m: Joe Salowey [mailto:jsalowey@cisco= .com]
>> Sent: Thursday, August 04, 2011 1:21 AM
>> To: Stephen Ha= nna
>> Cc: nea@ietf.org
>= ;> Subject: Re: Protecting L2 PT when proxying
>>
>> =
>> On Aug 3, 2011, at 5:47 PM, Stephen Hanna wrote:
>>
&= gt;> > My comments are inline below.
>> >
>> >= ; Joe Salowey wrote:
>> >> On Aug 3, 2011, at 7:28 AM, Steph= en Hanna wrote:
>> >>> We talked about this at length in the WG meeting last= week.
>> >>> I think we all agreed that both of the L2 P= T proposals MUST
>> >>> be carried in an EAP tunnel metho= d or equivalent protection.
>> >>> This will need to be an explicit requirement in the s= pec.
>> >>>
>> >>> The same requirement= s should apply to proxying PT beyond
>> >>> the end of th= e EAP tunnel method.
>> >>
>> >> [Joe] If you follow the above mandat= e then you would not expose PT-
>> EAP
>> >> outsid= e 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
&g= t;> >>> 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 conveya= nce over an
>> >>> untrusted network. I suppose we could = revise the proposals
>> >>> to include their own security measures so that they c= ould
>> >>> 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 tha= t 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 co= de in order to change
>> >> their behavior. While this ma= y seem harmless, it adds complexity
>> and
>> >> conspires against the extensible framewor= k that EAP and AAA are
>> built
>> >> upon. I agr= ee that there are multiple ways to protect an
>> attribute.
>> >> When proxying NEA data as an EAP method you are overloadi= ng 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 cre= ate an
>> >> attribute to carry PT data even if you are usin= g PT-EAP, which would
>> be
>> >> my preferred appr= oach if we are going to expose NEA data outside the
>> >> tunnel.
>> >
>> > PT-EAP is no mo= re a special case than any of the other EAP methods
>> > that c= annot safely be used without protections.
>>
>> [Joe] Fo= r 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 s= omething 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 attribu= te to extract the type
>> to determine how to protect the message. If you are going to prox= y
>> data which is sensitive then it must not be placed in a gener= ic EAP
>> attribute which is proxied without regard for protection= . Instead,
>> place it in its own attribute so implementations can treat it corr= ectly
>> by protecting the attribute or the entire packet.
>= >
>> > You may consider
>> > this to be difficu= lt 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 y= our employer to implement
>> > since you've designed your architecture around using TLVs= to carry
>> > posture but apparently this does not hold for ot= her implementations.
>> >
>>
>> [Joe] My con= cern 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 in= troduce
>> security vulnerabilities into their networks. I under= stand how
>> tempting it is to try to leverage some of the properties of EAP an= d AAA
>> as a implementation short cut, however it is often the ca= se that
>> implementation short cuts lead to security vulnerabilit= ies.
>>
>> > Thanks,
>> >
>> > Steve<= br>>> >
>> >>>> -----Original Message----->> >>>> From: Joe Salowey [mailto:jsalowey@cisco.com]
>> >>>> Sent: Wednesday, August 03, 2011 2:50 AM
>&= gt; >>>> 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:
>> >&= gt;>>
>> >>>>> <WG Chair Hat Off>
>> >>>>>
>> >>>>> I prefer opt= ion 1) PT-EAP.
>> >>>>>
>> >>>>= ;> My reasoning is that PT-EAP has been thoroughly vetted and widely
>> >>>>> implemented over the last five years. Also, i= t provides the best
>> >>>>> foundation for importa= nt 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 an= d other extensions. Currently in RADIUS, EAP is
>> >>>> carried directly within a RADIUS attribute with n= o additional
>> >>>> protection. For modern EAP metho= ds this is not a problem, since
>> >> they
>> >&= gt;>> provide sufficient protection from various forms of attack (as<= br> >> they
>> >>>> should since they are used on un= protected links). We have spent a
>> >> lot
>> >= ;>>> of effort moving away from EAP methods such as EAP-GTC and EA= P-MD5
>> >> that
>> >>>> are not strong. PT-EAP= is a step backwards in this regard.
>> >>>> Implement= ations will now have to be concerned about the protection
>> >&= gt;>> communications when an EAP attribute is being carried.
>> >> Alternatively,
>> >>>> if TLVs are u= sed a new RADIUS attribute can be defined to proxy
>> the
>&= gt; >>>> data if necessary. In addition, this attribute can be= designed to
>> >>>> provide the protection that is appropriate for NE= A data.
>> >>>>
>> >>>>> Thank= s,
>> >>>>>
>> >>>>> Steve<= br> >> >>>>>
>> >>>>> <WG Chair= Hat On>
>> >>>>>
>> >>>>&g= t;> -----Original Message-----
>> >>>>>> From= : nea-bounces@ietf.org [mailto:= nea-bounces@ietf.org] On
>> Behalf
>> >>>> Of
>> >>>>= ;>> Susan Thomson (sethomso)
>> >>>>>> Sen= t: Tuesday, August 02, 2011 5:04 PM
>> >>>>>> To= : nea@ietf.org
>> >>>>>> Subject: [Nea] Consensus check on EAP-bas= ed PT
>> >>>>>>
>> >>>>>= > At IETF81 and several prior IETF meetings, as well as on the
>&g= t; >> mailing
>> >>>>>> list, the WG has evaluated the pros and c= ons of 2 architectural
>> >>>>>> approaches to c= arrying posture within an EAP tunnel method:
>> >>>>&g= t;>
>> >>>>>> - EAP method
>> >>>>= >> http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-
>> 01.txt
>> >>>>>>
>> >>&g= t;>>> - EAP TLV.
>> >>>>>> http://www.ie= tf.org/internet-drafts/draft-cam-winget-eap-tlv-
>> >> 03.txt
>> >>>>>>
>> &= gt;>>>>> So far, there has been no WG consensus to adopt one= architecture
>> >>>> versus
>> >>>&= gt;>> the other. (At the recent F2F meeting in Quebec City, the
>> >> consensus
>> >>>>>> check at t= he meeting showed an equal number in favor of each
>> >>>= > approach.)
>> >>>>>>
>> >>&g= t;>>> This email is a final call to determine WG consensus on the = L2
>> PT
>> >>>>>> approach.
>> >= >>>>>
>> >>>>>> The consensus che= ck is to choose one of the following 3 options:
>> >>>>= ;>> 1) PT-EAP approach
>> >>>>>> 2) NEA-TLV approach
>> >>&= gt;>>> 3) Neither (please state the reason if you choose this opti= on)
>> >>>>>>
>> >>>>>&g= t; Please respond to the above question by Tues Aug 16 at 5pm PT.
>> >>>> Please
>> >>>>>> do>> >>>>>> so even if you have already expressed yo= ur opinion, either at a
>> WG
>> >>>>>>= meeting or on the mailing list. The answer can be as brief as
>> >>>> selecting
>> >>>>>> op= tion 1), 2) or 3). If you would like to add your reasons for
>> &g= t;> your
>> >>>>>> choice, that would be appr= eciated too, especially if you choose
>> >>>> option
>> >>>>>> 3).>> >>>>>>
>> >>>>>> If= we have consensus on the mailing list, we will adopt the
>> >&= gt; selected
>> >>>>>> approach.
>> >>>>>= ;>
>> >>>>>> If we still do not have consensu= s, the WG chairs and AD (Stephen
>> >>>>>> Farre= ll) have agreed that the AD will make a decision. The
>> >>>> proponents
>> >>>>>> o= f
>> >>>>>> 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
>> >>>>>&g= t; been received.
>> >>>>>>
>> >>>>>> In e= ither 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.
&= gt;> >>>>>>
>> >>>>>> Thank= s
>> >>>>>> Susan
>> >>>>>>= ;
>> >>>>>> ------------------
>> >&= gt;>>>> 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
>> >>>>>&g= t;
>> >>>>>> _________________________________________= ______
>> >>>>>> Nea mailing list
>> &g= t;>>>>> Nea@ietf.org
>> >>>>>> https://www.ietf.org/mailman/listinfo/nea
>> >= >>>> _______________________________________________
>>= ; >>>>> Nea mailing list
>> >>>>> Nea@ietf.org<= /a>
>> >>>>> https://www.ietf.org/mailman/listinfo/nea
>> &= gt;>>
>> >
>
> ____________________________________________= ___
> Nea mailing list
> Nea@ie= tf.org
> ht= tps://www.ietf.org/mailman/listinfo/nea
--000e0cdfc8bec00b6e04a9d6eef6-- From shanna@juniper.net Sat Aug 6 14:21:42 2011 Return-Path: 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 26EDA21F8634 for ; Sat, 6 Aug 2011 14:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 vselesRxwsI2 for ; Sat, 6 Aug 2011 14:21:41 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 03AF521F862F for ; Sat, 6 Aug 2011 14:21:39 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTj2weFJylKI6qqQj0rhaQvdrIgQzwwyM@postini.com; Sat, 06 Aug 2011 14:22:02 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 6 Aug 2011 14:20:57 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sat, 6 Aug 2011 17:20:56 -0400 From: Stephen Hanna To: Mike Fratto Date: Sat, 6 Aug 2011 17:20:55 -0400 Thread-Topic: [Nea] Protecting L2 PT when proxying Thread-Index: AcxURCsullIjpiCYSCG1HRNKFW7vvAAOo9OM Message-ID: <54A2F5AD-8A74-4FA3-9DD4-E7B19EC472EF@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 21:21:42 -0000 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 stac= k of Standards Track RFCs, from IF-M down to EAP. Thanks for pointing this out, though. There's no such requirement now in ei= ther of the PT proposals. Steve Sent from my Verizon Wireless 4GLTE smartphone ----- Reply message ----- From: "Mike Fratto" To: "Stephen Hanna" Cc: "nea@ietf.org" 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 de= fined as a MUST otherwise you run the risk of conformant but non-interopera= ble implementations. On Aug 5, 2011 5: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. > > 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: >> >>>> >> >>>>> >> >>>>> >> >>>>> 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 >> >>>>> >> >>>>> >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: nea-bounces@ietf.org [mailto:n= ea-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 From jsalowey@cisco.com Mon Aug 8 12:38:39 2011 Return-Path: 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 668E85E8008 for ; Mon, 8 Aug 2011 12:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.028 X-Spam-Level: X-Spam-Status: No, score=-104.028 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jjtJWjz6ByA for ; Mon, 8 Aug 2011 12:38:38 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 054C45E8007 for ; Mon, 8 Aug 2011 12:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=12933; q=dns/txt; s=iport; t=1312832345; x=1314041945; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=upO4vHhmgCO1ZAQnh/hkCDWRmr/qT1Hg1kB97dd8Q84=; b=kB9Ptrw3DK343EiTSQ5Ho+X7NRGuOu/NAcapCletmTyeoGlLtAKUSum1 kzA2+xYrPaydRkdY9lt7W0PGHZ0KtELVI4XFlwO/K1zSexOCWk+fuLSRm GTNoZHTGHrx1vMElcsGYvZJG/zDh8UA253k2TfmyHyXTHaYMpRa53qPnh U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAKM6QE6rRDoI/2dsb2JhbAA6CZdYj093gUABAQEBAgEBAQEPASctBwsFBwQLDgMBAwEBAScHJx8DBggGEwkZh0sEn2YBnmuDKIJAXwSHXIsmhQiMAA X-IronPort-AV: E=Sophos;i="4.67,338,1309737600"; d="scan'208";a="10957624" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-7.cisco.com with ESMTP; 08 Aug 2011 19:39:04 +0000 Received: from [10.33.249.202] ([10.33.249.202]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p78Jd2c5026297; Mon, 8 Aug 2011 19:39:03 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Mon, 8 Aug 2011 12:39:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <65E8B2E4-E884-4B15-AB33-F410BBF37065@cisco.com> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> <5A2C9B76-7BC5-48A5-B5DC-C9E99E135B29@cisco.com> <9CF77382-FF31-4ADA-9A56-64A23380FABF@cisco.com> To: Stephen Hanna X-Mailer: Apple Mail (2.1084) Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 19:38:39 -0000 On Aug 5, 2011, at 2:38 PM, Stephen Hanna wrote: > Joe, >=20 > 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. >=20 > 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. >=20 > 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. >=20 [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. =20 > 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." >=20 [Joe] I don't quite follow your proposal, it seems complex to protect = data beyond the tunnel using the tunnel. Here is my suggestion: =20 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. =20= 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. =20 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.=20 > Thanks, >=20 > Steve >=20 >> -----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 >>=20 >>=20 >> On Aug 3, 2011, at 5:47 PM, Stephen Hanna wrote: >>=20 >>> My comments are inline below. >>>=20 >>> 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. >>>>>=20 >>>>> The same requirements should apply to proxying PT beyond >>>>> the end of the EAP tunnel method. >>>>=20 >>>> [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. >>>=20 >>> 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. >>>=20 >>>>> 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. >>>>>=20 >>>> [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. >>>=20 >>> PT-EAP is no more a special case than any of the other EAP methods >>> that cannot safely be used without protections. >>=20 >> [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. >>=20 >>> 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. >>>=20 >>=20 >> [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. >>=20 >>> Thanks, >>>=20 >>> Steve >>>=20 >>>>>> -----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 >>>>>>=20 >>>>>>=20 >>>>>> On Aug 2, 2011, at 3:54 PM, Stephen Hanna wrote: >>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>> I prefer option 1) PT-EAP. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>> [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. >>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Steve >>>>>>>=20 >>>>>>> >>>>>>>=20 >>>>>>>> -----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 >>>>>>>>=20 >>>>>>>> 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: >>>>>>>>=20 >>>>>>>> - EAP method >>>>>>>> http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap- >> 01.txt >>>>>>>>=20 >>>>>>>> - EAP TLV. >>>>>>>> http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv- >>>> 03.txt >>>>>>>>=20 >>>>>>>> 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.) >>>>>>>>=20 >>>>>>>> This email is a final call to determine WG consensus on the L2 >> PT >>>>>>>> approach. >>>>>>>>=20 >>>>>>>> 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) >>>>>>>>=20 >>>>>>>> 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). >>>>>>>>=20 >>>>>>>> If we have consensus on the mailing list, we will adopt the >>>> selected >>>>>>>> approach. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> 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. >>>>>>>>=20 >>>>>>>> Thanks >>>>>>>> Susan >>>>>>>>=20 >>>>>>>> ------------------ >>>>>>>> References: >>>>>>>> IETF81 audio session (start at approx 44 mins into session): >>>>>>>> http://www.ietf.org/audio/ietf81/ietf81-2103-20110727-1256- >> pm.mp3 >>>>>>>>=20 >>>>>>>> IETF81 draft meeting minutes: >>>>>>>> http://tools.ietf.org/wg/nea/minutes >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>=20 >>>=20 >=20 From kaushik@cisco.com Mon Aug 8 13:32:25 2011 Return-Path: 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 707BB5E8001 for ; Mon, 8 Aug 2011 13:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbUZRxVbfl+Y for ; Mon, 8 Aug 2011 13:32:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C386621F8BB0 for ; Mon, 8 Aug 2011 13:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kaushik@cisco.com; l=2997; q=dns/txt; s=iport; t=1312835572; x=1314045172; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0UjIJqk8mzvJpkYGUyv9l9T8T5HT71zPwv4XEjTAVU0=; b=eViYxSboK1eR43udNPuNsvEy0tz43ztGwUYmKnAECxY/A901qRfasIWd Lzx6cvq4O30ttkqct/7OA9alJaVUbFiINTkfs/ff2l9Z51fcCuh1gLPjP VTdUkCf4Mrxf4HMygnT3UCtkV6PrXjad8vA+paPq6yC1tegtZbgX7eu04 U=; X-IronPort-AV: E=Sophos;i="4.67,339,1309737600"; d="scan'208";a="10971749" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-2.cisco.com with ESMTP; 08 Aug 2011 20:32:51 +0000 Received: from [10.34.79.68] ([10.34.79.68]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p78KWoh3031601; Mon, 8 Aug 2011 20:32:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: kaushik narayan In-Reply-To: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> Date: Mon, 8 Aug 2011 13:32:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <84A2340E-CC1F-4226-8C0C-F52FD754A8A7@cisco.com> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> To: Susan Thomson (sethomso) X-Mailer: Apple Mail (2.1084) Cc: nea@ietf.org Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 20:32:25 -0000 I prefer EAP TLV method. I was wondering whether this question should be debated in EMU as well = since the question is less about NEA and more about how to use EAP as a carrier for NEA. EAP-TNC = creates an EAP method to =20 carry application data (posture is pretty much an opaque data exchange = for EAP) and creates a precedent=20 for other EAP methods to defined to carry arbitrary data sets. I would = presume the EMU folks might want to say something about that. regards, kaushik=20 On Aug 2, 2011, at 2:04 PM, Susan Thomson (sethomso) wrote: > 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:=20 >=20 > - EAP method=20 > http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-01.txt >=20 > - EAP TLV. > http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt >=20 > 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.) >=20 > This email is a final call to determine WG consensus on the L2 PT > approach.=20 >=20 > 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) >=20 > 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). >=20 > If we have consensus on the mailing list, we will adopt the selected > approach. >=20 > 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. >=20 > 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. >=20 > Thanks > Susan >=20 > ------------------ > References: > IETF81 audio session (start at approx 44 mins into session):=20 > http://www.ietf.org/audio/ietf81/ietf81-2103-20110727-1256-pm.mp3 >=20 > IETF81 draft meeting minutes: > http://tools.ietf.org/wg/nea/minutes >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From Paul_Sangster@symantec.com Tue Aug 9 09:03:18 2011 Return-Path: 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 30B7921F8C7F for ; Tue, 9 Aug 2011 09:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0eDLvM3s6XJ for ; Tue, 9 Aug 2011 09:03:17 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3A48621F8C49 for ; Tue, 9 Aug 2011 09:03:16 -0700 (PDT) X-AuditID: d80ac3f1-b7c8dae000001039-4c-4e415a60fab2 Received: from tus1smtintpin02.ges.symantec.com (TUS1SMTINTPIN02.ges.symantec.com [192.168.215.102]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id CF.3E.04153.06A514E4; Tue, 9 Aug 2011 09:03:44 -0700 (MST) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1smtintpin02.ges.symantec.com with esmtp (Exim 4.72) (envelope-from ) id 1QqomO-0004vQ-5e; Tue, 09 Aug 2011 09:03:44 -0700 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Tue, 9 Aug 2011 09:03:44 -0700 From: Paul Sangster To: Susan Thomson Date: Tue, 9 Aug 2011 09:03:42 -0700 Thread-Topic: [Nea] Consensus check on EAP-based PT Thread-Index: AcxWCmFrDQLBgxZmQkmK7nzeXMQe/AAoJ2KQ Message-ID: <6E79D623502C70419A9EAB18E4D274252A6AF4039A@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> <84A2340E-CC1F-4226-8C0C-F52FD754A8A7@cisco.com> In-Reply-To: <84A2340E-CC1F-4226-8C0C-F52FD754A8A7@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsVyYMX1NN2EKEc/gx9bxCw+v62weLpmCpMD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbH77zW2ghtqFX0X/rI2MDbLdzFyckgImEh8 enCXHcIWk7hwbz1bFyMXh5DAR0aJbUuuQjmvGSWu7LjFBFIlJLCSUeLyCm4Qm03AQGLnkVNg 3SICahI/PzwGs5kFFCWmty4Fq2cRUJFYPOkxK4gtLGAk8ebvUVaIemOJ++/7mCBsI4lvf58x g9i8AlESHVO6WSB21Urc3noJLM4pYCvR8nkbmM0IdOn3U2uYIHaJS9x6Mp8J4gMBiSV7zjND 2KISLx//Y4WoF5W4076eEaJeR2LB7k9sELa2xLKFr6H2CkqcnPmEZQKj+CwkY2chaZmFpGUW kpYFjCyrGGVKSosNi3NL8ktLClIrDAz1iitzE4ERlqyXnJ+7iREYZTe4Dn/cwXh9qeIhRgEO RiUe3lthjn5CrIllQJWHGCU4mJVEeOeBhHhTEiurUovy44tKc1KLDzFKc7AoifPOfGDkJySQ nliSmp2aWpBaBJNl4uCUamBsNWO9bbVnYvEqpRO2t5a++Ps0Qql98sMqJ+Mv6Sxn5JfsCT8c IX4/xemF5dWdJyu2PT4ZlOik1v/knL/305hNt7TXHLjC+ptD7tuiCRv0uWbomWhcmn3+y6NP 3TvvnyrkcXFesHOupPXni/OsVBVLv+borlyqkRNdLfunby7LMd+jB7z/Fss9UGIpzkg01GIu Kk4EAGfhMIGuAgAA Cc: "nea@ietf.org" Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 16:03:18 -0000 My vote is for PT-EAP. It's my current view that both proposals are very close functionally and I = don't see a compelling reason to select a TLV based approach. I believe we= should follow RFC 5209 which discusses the selection criteria for NEA prot= ocols. Again both approaches meet most of the requirements, however PT-EAP= is already fully documented in a public standards based spec. If that's n= ot enough, we have a lot of implementation experience with PT-EAP with 9 in= dependent implementations, many plugfests, clarification updates to the ori= ginal spec (factoring in implementer feedback) and even compliance tests us= ing a test suite specifically designed to test implementations. Also, I th= ink we should consider the Tao of the IETF in this particularly:=20 "One of the "founding beliefs" is embodied in an early quote about the = IETF from David Clark: "We reject kings,=20 presidents and voting. We believe in rough consensus and running code". On the implementation side, we actually have the OpenSEA Alliance supplican= t which supports EAP-TNC carrying PB-TNC and PA-TNC, so we know the stack w= orks well together and the implementers have reported no significant or unu= sual issues during the development (not even to the EAP engine). It sounds like the discussion about protection of the inner method (or TLVs= ) carrying the posture could be addressed by adding security to either prop= osal. I've not been convinced this is a serious problem that we can solve = with words in a specification, since the root cause seems to be administrat= or misconfiguration/use of a product potentially resulting in weak security= . Administrator errors are hard to solve in standards specs unless we prec= lude any compliant product from ever being configured to potentially be not= secure. This is difficult and doesn't allow for deployments where they ha= ve addressed the security threats via other countermeasures (e.g. link encr= yption, proxied EAP over an encrypted link, physical isolation, ...). I do= think we should require implementation of core security features, but requ= iring their use in all situations is something we would need to discuss mor= e. >=20 >=20 >=20 > On Aug 2, 2011, at 2:04 PM, Susan Thomson (sethomso) wrote: >=20 > > 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 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From mccann.stephen@gmail.com Fri Aug 12 02:23:23 2011 Return-Path: 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 4E4E621F8665 for ; Fri, 12 Aug 2011 02:23: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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT7zODR08Uq3 for ; Fri, 12 Aug 2011 02:23: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 4F8CB21F8519 for ; Fri, 12 Aug 2011 02:23:22 -0700 (PDT) Received: by iye1 with SMTP id 1so1639953iye.27 for ; Fri, 12 Aug 2011 02:23:58 -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 :content-type:content-transfer-encoding; bh=hJzRFUas+YuRA90qsg81y4K3Sjx7DoQTvR2Uq03rGrg=; b=DTgP4i7Jjq1dzmcdYeWa+mKPzes4K7jEh/hMVfBCyAMp0Jgur1reCvFJHPDdt4uv9C bKeHuc84qTZzmBFKKOXXxJQNt7Mon/C6N/yBnkr0Rp4IwrUAuFOjRUA+yu+jIkqt9mzt lDpycFIt6F0R0OVBu+qY+kR4La//C0qGL4O3k= MIME-Version: 1.0 Received: by 10.231.217.93 with SMTP id hl29mr1488906ibb.41.1313141038808; Fri, 12 Aug 2011 02:23:58 -0700 (PDT) Received: by 10.231.6.88 with HTTP; Fri, 12 Aug 2011 02:23:58 -0700 (PDT) In-Reply-To: References: <6065F7697E427240893C1B5CF41828967EF7D4@XMB-RCD-111.cisco.com> <84A2340E-CC1F-4226-8C0C-F52FD754A8A7@cisco.com> Date: Fri, 12 Aug 2011 10:23:58 +0100 Message-ID: From: Stephen McCann To: nea@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Nea] Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 09:23:23 -0000 Dear all, =A0 =A0 =A0 =A0 =A0 =A0 my choice is for option 2) Kind regards Stephen >> On Aug 2, 2011, at 2:04 PM, Susan Thomson (sethomso) wrote: >> >>> 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 d= o >>> 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 o= f >>> 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 hav= e >>> 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 >> > From sethomso@cisco.com Thu Aug 18 15:34:33 2011 Return-Path: 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 40B0A21F8B14 for ; Thu, 18 Aug 2011 15:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=-2.400, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDa1HN4UgmKU for ; Thu, 18 Aug 2011 15:34:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9696B21F8B0F for ; Thu, 18 Aug 2011 15:34:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=3478; q=dns/txt; s=iport; t=1313706928; x=1314916528; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=cQRpU/MSUv5jhTW1xqDsHhqXWXcSki+qj75afjVzstk=; b=RFSlsGqJKpv5izkzZNcnC2GjWg0GI89vLfKjQHzSWKlx3c9KS6O+IddE h32HHSQq0wc4Y+lab5Dnd4TG+jAcEY6tB756900oWVdhiCAB79+hhP72n K0wCaoP87OGvAts6wj7PZMBQERp/oeP+tNkpIgMx8+PDU1/yunpK6C2pI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKuSTU6tJV2a/2dsb2JhbABCp3d3gUABAQEBAxIBCh0CATEdARkBAgECeAYIAQEEEwkZh1OWcoEjAZ8JhkgEkxOFFYt8 X-IronPort-AV: E=Sophos;i="4.68,247,1312156800"; d="scan'208";a="14495252" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 18 Aug 2011 22:35:27 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p7IMZR5B001995 for ; Thu, 18 Aug 2011 22:35:27 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 18 Aug 2011 17:35:27 -0500 Received: from 10.116.64.107 ([10.116.64.107]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 18 Aug 2011 22:35:27 +0000 User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Thu, 18 Aug 2011 18:35:26 -0400 From: Susan Thomson To: Message-ID: Thread-Topic: Results of Consensus check on EAP-based PT Thread-Index: AcxRV8K12t9ayfNhRg2m5tY+ll6mrAMn10rq In-Reply-To: <24923AF17BDA9B43A2DBEBD29861FFBFAA395415@XMB-RCD-111.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 18 Aug 2011 22:35:27.0396 (UTC) FILETIME=[20B54E40:01CC5DF7] Subject: [Nea] Results of Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 22:34:33 -0000 We have come to the end of the consensus check period for selecting an EAP-based approach to PT. By my count, the results were as follows: PT-EAP: 11 EAP-TLV: 8 Since there is still no consensus, we will follow the process outlined in the original call for consensus check message (see below), where our AD, Stephen Farrell, will make a decision. As discussed at the last meeting, we expect to receive a decision in August. The next step after that is to publish the individual submission corresponding to the selected approach as a -00 NEA WG I-D, and we will proceed with the normal process of editing the document within the WG. I want to thank everyone for participating in the consensus check, and to those who provided the reasons behind their decision. I especially want to thank the proponents of the two proposals for providing a framework for evaluating the approaches. I think the discussion provides valuable input into the decision-making process and shows that due diligence has been done. Thanks Susan ------ Forwarded Message > From: sethomso > Date: Tue, 2 Aug 2011 16:04:25 -0500 > To: > Subject: 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 > ------ End of Forwarded Message From stephen.farrell@cs.tcd.ie Wed Aug 24 15:41:20 2011 Return-Path: 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 B9D1A21F8C6B for ; Wed, 24 Aug 2011 15:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJAVXy0mnOOI for ; Wed, 24 Aug 2011 15:41:20 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5E221F8B47 for ; Wed, 24 Aug 2011 15:41:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D4F50171C5B; Wed, 24 Aug 2011 23:42:27 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1314225746; bh=bT/uqod8I/GazT EwLxanU9WH9uOOfnxpYU7/yvpgXCA=; b=ifexmF6lptyswq9qPzvU8tIs9cPWq+ +8qAmyXqCuznq0rZRcse4xhWh5Ndic8XRkynnsGqCnOswrcXcMGwsQitqqHtqUKM baUI6A19rxt026GEG7+1GAC+eX+qJtTDnf1WWNYDZjSWcnKoi/0Mu1BqEBB1+VlA 5qI9IpAd2brGbZBgMyEGW/63V3RdmMIBA4hH1KsXiZ1h8jxUomN15DDz8wBVD9WF YQFnRT6nwcW9hMtHTfwQXklXaaN1c5qHTZF4NotT/KezsZ7MpthaXocnUq1Cn0sY FgBqQZIv4xbNW7r3StJ/jJuDQIROmCakE/UWK1t2u+i4dv8SrRQAsVGw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id spyeXQpDh6nd; Wed, 24 Aug 2011 23:42:26 +0100 (IST) Received: from [10.87.48.7] (unknown [86.46.30.197]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 41521171C1B; Wed, 24 Aug 2011 23:42:25 +0100 (IST) Message-ID: <4E557E47.7040305@cs.tcd.ie> Date: Wed, 24 Aug 2011 23:42:15 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Susan Thomson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: nea@ietf.org Subject: Re: [Nea] Results of Consensus check on EAP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 22:41:20 -0000 Hi all, The requested decision is at the end, so you can skip there first if you're only keen on the outcome:-) Firstly, I entirely agree with the WG that picking one way to do this is the way to go - other WGs with which I've been involved have regretted standardising two ways to do the same thing for years afterwards, so thanks for being open to even a pretty unqualified selection process, (i.e. having me pick) - I think you're doing the right thing in pushing hard for one standard. I'd also like to thank the chairs for their leadership of what could have been a quite divisive discussion - they're either good at that or else you're all much more polite than the average set of IETF participants:-) Second, I also agree with the WG that basically either approach could work so there's not much difference here, and that's probably one of the reasons why its been hard to reach a decision. Third, I also agree with the chairs that there is no rough consensus in the WG, neither on the list nor at the last couple of face to face meetings. My own reading of the situation is that PT-EAP does provide a firmer basis on which to go forward at this stage, given that there are implementations that have been deployed that are very similar. That was also backed up by a few off-list responses I got from people who know more about this than I but who are not involved in the WG. When I asked which way they thought would be better, one said doing it in EAP is crazy for size reasons, but most (4 to 2) said that the running code should win. However, I also agree with the argument that EAP-TLV is more in line with the direction in which EAP standardisation has been going, i.e. avoiding new less-secure EAP method definitions. OTOH, there are so many existing EAP methods, that its hard to see this as a showstopper. The other thing that strikes me is that neither approach is yet fully baked, in particular, the WG will still need to figure the detail of how to handle requirement PT-2 from RFC 5209, copied below: "PT-2 The PT protocol MUST be capable of supporting mutual authentication, integrity, confidentiality, and replay protection of the PB messages between the Posture Transport Client and the Posture Transport Server." My feeling is that the two already-similar proposals might look even more similar when a solution meeting that requirement is developed in the WG. (That solution might involve just an EAP tunnel or maybe more.) And that might (or might not) lead to a change in the WG consensus depending on how that solution looks. If a change in the WG opinion did happen later on I don't believe that switching to TLVs would be that much work at that point (as otherwise the WG consensus would presumably not be for change), so even if a change were done later I don't see it adding much delay. But of course, we don't want to get wedged again on a lack of consensus. So, taking all the above into account, I propose the following: - Proceed with PT-EAP: make draft-hanna-nea-pt a WG draft, and develop that until its ready for WGLC - At WGLC time, if called upon to do so by a WG participant, the chairs are to hold a new consensus call to see if WG consensus has in fact moved to using TLVs rather than an EAP method, *but* with a default that no consensus for change to TLVs at that point means staying with the EAP method approach of PT-EAP Note that this does not call for the proponents of EAP-TLV to continue developing their approach independently. My hope is that they get involved with the WG document and then, when that's ready, make their argument for a change to TLVs again, if they still feel that's useful. Regards, Stephen. From internet-drafts@ietf.org Tue Aug 30 13:38:15 2011 Return-Path: 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 6793921F8D5B; Tue, 30 Aug 2011 13:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7j2L1YqHlwW; Tue, 30 Aug 2011 13:38:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C288021F8D43; Tue, 30 Aug 2011 13:38:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110830203814.25475.25493.idtracker@ietfa.amsl.com> Date: Tue, 30 Aug 2011 13:38:14 -0700 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-eap-00.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Aug 2011 20:38:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Endpoint Assessment Working G= roup of the IETF. Title : PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel M= ethods Author(s) : Paul Sangster Nancy Cam-Winget Filename : draft-ietf-nea-pt-eap-00.txt Pages : 29 Date : 2011-08-30 This document specifies PT-EAP, a Posture Broker Protocol compatible with the Trusted Computing Group's IF-T Protocol Bindings for Tunneled EAP Methods (also known as EAP-TNC). The document then evaluates PT-EAP against the requirements defined in the NEA Requirements and PB-TNC specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-eap-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-nea-pt-eap-00.txt