From latze@angry-red-pla.net Fri Jul 1 07:05:32 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 F2A1A1F0C51 for ; Fri, 1 Jul 2011 07:05:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrLwwqavIg1x for ; Fri, 1 Jul 2011 07:05:32 -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 A253211E80DE for ; Fri, 1 Jul 2011 07:05:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=thuvia.angry-red-pla.net) by thuvia.angry-red-pla.net with esmtp (Exim 4.69) (envelope-from ) id 1QceLW-0006sQ-In for nea@ietf.org; Fri, 01 Jul 2011 16:05:27 +0200 Received: from 188.61.140.32 (SquirrelMail authenticated user latze) by thuvia.angry-red-pla.net with HTTP; Fri, 1 Jul 2011 16:05:26 +0200 (CEST) Message-ID: In-Reply-To: <6065F7697E427240893C1B5CF41828963DD9AD@XMB-RCD-111.cisco.com> References: <6065F7697E427240893C1B5CF41828963DD9AD@XMB-RCD-111.cisco.com> Date: Fri, 1 Jul 2011 16:05:26 +0200 (CEST) From: latze@angry-red-pla.net To: nea@ietf.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [Nea] Please REVIEW PT-TLS I-D 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, 01 Jul 2011 14:05:33 -0000 few comments/ questions from my side: - reference to [PT-EAP]: does it make sense to mention a specific draft that might be different from the final RFC? I might be better to mention an "EAP based assessment" instead - section 3.1.1: would it make sense to specify how to keep the TLS session alive? I think it might be helpful to ensure interoperability - section 3.4.2.1, line 5: lost "," :-) - section 3.6, type 8: maybe provide a "real" reference to the PB-TNC specification? - section 3.9, error code 6: why is the "SASL mechanism error" handled as fatal while "Failed Authentication" is not? I would suspect both errors should be handled the same since both end up with an unauthenticated client? - section 4.1.1: "... is trusted to ... expose the authenticated identity of the Posture Transport Server". I would suspect that the client is trusted *not to expose* the server's identity? (same in section 4.1.2) - there are some missing new lines before the following sections: 2.1, 2.3, 3.2, 3.3, 3.4.1, 3.4.2.1, 3.4.3, 3.5, 3.7.1, 4.1 - there is a missing new line after the title of section 3.4.2.3 I hope the comments are helpful. regards Carolin > This is a call for comments on the NEA working group document: > > http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-00.txt > > Please take the time to review the document and provide comments to the > NEA mailing list prior to the IETF meeting (by Fri Jul 22). > > This will allow us to address outstanding issues at the meeting in > Quebec City, and revise the document in preparation for a WG Last Call > in August. > > Thanks > Susan > > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Monday, June 13, 2011 12:45 PM > To: i-d-announce@ietf.org > Cc: nea@ietf.org > Subject: [Nea] I-D Action: draft-ietf-nea-pt-tls-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Network Endpoint > Assessment Working Group of the IETF. > > Title : PT-TLS: A Posture Transport (PT) Protocol > Based on Transport Layer Security (TLS) > Author(s) : Paul Sangster > Nancy Cam-Winget > Joseph Salowey > Filename : draft-ietf-nea-pt-tls-00.txt > Pages : 49 > Date : 2011-06-13 > > This document specifies PT-TLS, a Posture Transport (PT) protocol > that carries the Network Endpoint Assessment (NEA) message exchange > under the protection of a Transport Layer Security (TLS) secured > tunnel. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-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-tls-00.txt > _______________________________________________ > 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 llorenzin@juniper.net Tue Jul 12 11:27: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 40A6F21F8DCE for ; Tue, 12 Jul 2011 11:27: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 0MwppdOGP+7V for ; Tue, 12 Jul 2011 11:27:51 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 30E5E21F8B2F for ; Tue, 12 Jul 2011 11:27:45 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKThySIH/ib4TtPPBvrXpQ07FSjz6euSob@postini.com; Tue, 12 Jul 2011 11:27:45 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 12 Jul 2011 11:24:48 -0700 From: Lisa Lorenzin To: "nea@ietf.org" Date: Tue, 12 Jul 2011 11:24:48 -0700 Thread-Topic: CALL for COMMENTS on EAP PT approaches Thread-Index: Acw3dWecgPzMKxGHRLuTrVuREyOhaQJP2b7w Message-ID: <189716C74BBB9C4095FE8CA503B1FC3A5525C6A885@EMBX02-HQ.jnpr.net> References: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> In-Reply-To: <6065F7697E427240893C1B5CF41828963DD9AE@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] CALL for COMMENTS on EAP PT approaches 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, 12 Jul 2011 18:27:52 -0000 Greetings! Based on the meeting minutes and previous discussion thread, it looks to me like a) there are pros and cons to each approach, and b) either approach would accomplish the technical goals. In the absence of a clear technical front-runner, layer 8 considerations take on greater significance. Since PT-EAP has many more technical implementations, and is based on an open standard from TCG, it seems to better conform to the IETF's emphasis on running code, and to better comply with the RFC 5209 requirement to "prefer the reuse of existing open standards that meet the requirements before defining new ones." Based on those considerations, PT-EAP seems like a better choice. Regards, Lisa > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On > Behalf Of Susan Thomson (sethomso) > Sent: Thursday, June 30, 2011 18:31 > To: nea@ietf.org > Subject: [Nea] CALL for COMMENTS on EAP PT approaches > > One of the outstanding items in the NEA WG is to come to consensus on > whether to use EAP method or TLV for carrying NEA data in an EAP-based > transport. > > Steve Hanna has initiated a thread on this topic on the > mailing list to > which some have responded (see pointer below to email thread and to > meeting minutes for summary of discussion at IETF 80). > > We need more input from the WG to make a decision. Please review the > pros and cons laid out in the thread and provide your input. Feedback > may include any considerations that you think might be > missing from the > discussion, as well how you would weigh the characteristics of the two > approaches. > > The deadline for making a decision is by the July IETF. If we do not, > our AD has "offered" to make the decision for us! So please take the > time to post your views. I think it would reflect poorly on > the WG if we > are unable to come to consensus ourselves. > > Thanks > Susan > > Email Thread starts here: > http://www.ietf.org/mail-archive/web/nea/current/msg01120.html > > Meeting minutes from IETF 80: > http://tools.ietf.org/wg/nea/minutes?item=3Dminutes80.html > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > From Paul_Sangster@symantec.com Tue Jul 12 13:28: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 AF45E21F8736 for ; Tue, 12 Jul 2011 13:28:53 -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 MUTTz-RX6ZDl for ; Tue, 12 Jul 2011 13:28:49 -0700 (PDT) Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) by ietfa.amsl.com (Postfix) with ESMTP id AFA4021F876B for ; Tue, 12 Jul 2011 13:28:49 -0700 (PDT) X-AuditID: a66201d1-b7cefae00000787b-38-4e1cae7e109a Received: from tus1smtintpin02.ges.symantec.com (TUS1SMTINTPIN02.ges.symantec.com [192.168.215.102]) by ecl1mtaoutpex01.symantec.com (Symantec Messaging Gateway) with SMTP id EE.26.30843.E7EAC1E4; Tue, 12 Jul 2011 16:28:46 -0400 (EDT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by tus1smtintpin02.ges.symantec.com with esmtp (Exim 4.72) (envelope-from ) id 1QgjZW-0003ou-5W; Tue, 12 Jul 2011 13:28:46 -0700 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Tue, 12 Jul 2011 13:28:46 -0700 From: Paul Sangster To: Lisa Lorenzin , "nea@ietf.org" Date: Tue, 12 Jul 2011 13:28:47 -0700 Thread-Topic: CALL for COMMENTS on EAP PT approaches Thread-Index: Acw3dWecgPzMKxGHRLuTrVuREyOhaQJP2b7wAAdC3xA= Message-ID: <6E79D623502C70419A9EAB18E4D274252A6A1ADBD2@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> <189716C74BBB9C4095FE8CA503B1FC3A5525C6A885@EMBX02-HQ.jnpr.net> In-Reply-To: <189716C74BBB9C4095FE8CA503B1FC3A5525C6A885@EMBX02-HQ.jnpr.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42I5sOJ6mm7dOhk/gwn/1S1+PpvKYvH5bYUD k8eSJT+ZPK43XWUPYIrisklJzcksSy3St0vgymg4soK1YI14xaHZSg2MfwW7GDk5JARMJI7N OcsIYYtJXLi3nq2LkYtDSOANo8SJa2+ZQRJCAq8ZJTYelYNIrGKU2PtjEwtIgk3AQGLnkVPs ILaIgIfEv8nX2EBsFgFViQOrboI1CwuYSaw7dYURosZcYtHLZUwQtpXE/XldYL28AlESW3/1 M0Es6GGUaOiYClbEKeAjse3fQVYQmxHovO+n1oDFmQXEJW49mc8EcbaAxJI955khbFGJl4// QdWLStxpX88IUa8jsWD3JzYIW1ti2cLXzBCLBSVOznzCMoFRbBaSsbOQtMxC0jILScsCRpZV jDKpyTmGuSWJ+aUlBakVBoZ6xZW5icBIStZLzs/dxAiMpmVJjBd3MF44rHuIUYCDUYmHl2e5 jJ8Qa2IZUOUhRgkOZiUR3vwZQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Cn9Z/YQE0hNLUrNT UwtSi2CyTBycUg2M3ssWrhV1FNapuGP5gGFPQcGPo8uPzIormLjv+4O//6xub77dtzs72s83 YzrfpZ0M4gcF2hJ6dMzvBkxUjA/Zt35adpT5POX09nWxNoGmLL2rmFqOfnxqKd27/NrZTe8X T57/YFbx02fre7/tz//qkZooMLP18q36C8Hcz8x35h5b9Ob5zL3/FZVYijMSDbWYi4oTASco sDCiAgAA Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches 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, 12 Jul 2011 20:28:53 -0000 Well said Lisa, I have to agree with your comments. > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Lisa Lorenzin > Sent: Tuesday, July 12, 2011 11:25 AM > To: nea@ietf.org > Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches >=20 > Greetings! >=20 > Based on the meeting minutes and previous discussion thread, > it looks to me like a) there are pros and cons to each > approach, and b) either approach would accomplish the > technical goals. >=20 > In the absence of a clear technical front-runner, layer 8 > considerations take on greater significance. Since PT-EAP > has many more technical implementations, and is based on > an open standard from TCG, it seems to better conform to > the IETF's emphasis on running code, and to better comply > with the RFC 5209 requirement to "prefer the reuse of > existing open standards that meet the requirements before > defining new ones." >=20 > Based on those considerations, PT-EAP seems like a better > choice. >=20 > Regards, >=20 > Lisa >=20 > > -----Original Message----- > > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On > > Behalf Of Susan Thomson (sethomso) > > Sent: Thursday, June 30, 2011 18:31 > > To: nea@ietf.org > > Subject: [Nea] CALL for COMMENTS on EAP PT approaches > > > > One of the outstanding items in the NEA WG is to come to consensus on > > whether to use EAP method or TLV for carrying NEA data in an EAP- > based > > transport. > > > > Steve Hanna has initiated a thread on this topic on the > > mailing list to > > which some have responded (see pointer below to email thread and to > > meeting minutes for summary of discussion at IETF 80). > > > > We need more input from the WG to make a decision. Please review the > > pros and cons laid out in the thread and provide your input. Feedback > > may include any considerations that you think might be > > missing from the > > discussion, as well how you would weigh the characteristics of the > two > > approaches. > > > > The deadline for making a decision is by the July IETF. If we do not, > > our AD has "offered" to make the decision for us! So please take the > > time to post your views. I think it would reflect poorly on > > the WG if we > > are unable to come to consensus ourselves. > > > > Thanks > > Susan > > > > Email Thread starts here: > > http://www.ietf.org/mail-archive/web/nea/current/msg01120.html > > > > Meeting minutes from IETF 80: > > http://tools.ietf.org/wg/nea/minutes?item=3Dminutes80.html > > > > > > _______________________________________________ > > 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 andreas.steffen@strongswan.org Thu Jul 14 12:38:56 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 A296E21F8768 for ; Thu, 14 Jul 2011 12:38:56 -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 24D1AdRInFPA for ; Thu, 14 Jul 2011 12:38:48 -0700 (PDT) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by ietfa.amsl.com (Postfix) with ESMTP id 19BE721F8748 for ; Thu, 14 Jul 2011 12:38:47 -0700 (PDT) Received: from [10.10.0.20] by strongswan.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1QhRk4-0002tH-KJ; Thu, 14 Jul 2011 21:38:36 +0200 Message-ID: <4E1F45C5.4070302@strongswan.org> Date: Thu, 14 Jul 2011 21:38:45 +0200 From: Andreas Steffen Organization: strongSwan Project User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110516 Thunderbird/3.1.10 MIME-Version: 1.0 To: nea@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Nea] Pros and cons of EAP and TLVs for L2 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, 14 Jul 2011 19:38:56 -0000 Hello, for the strongSwan project we implemented TCG EAP-TNC as an inner protocol, embedded into EAP-TTLS AVPs to transport PB-TNC batches over an IKEv2 EAP communications channel. 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. If a TLV representation would be used for the PT protocol, then a differentiation between EAP and TLV packets would have to be made which reminds somehow me of the chaos Microsoft created with their mixture of EAP and TLV packets in MS-PEAP. I would welcome a TLV PT protocol, though, if it would be possible to have the same PT standard format for both L2/L3 tunneled EAP and L4 TLS, so that only a single implementation would be required. Best regards Andreas ====================================================================== 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 stefan.winter@restena.lu Thu Jul 21 05:49:29 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 B004721F891F for ; Thu, 21 Jul 2011 05:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.312, 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 atbKoqzZYcCl for ; Thu, 21 Jul 2011 05:49:29 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9B95F21F8579 for ; Thu, 21 Jul 2011 05:49:28 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 3F96D10590 for ; Thu, 21 Jul 2011 14:49:27 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2AAF510584 for ; Thu, 21 Jul 2011 14:49:27 +0200 (CEST) Message-ID: <4E282057.5060602@restena.lu> Date: Thu, 21 Jul 2011 14:49:27 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: nea@ietf.org References: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> In-Reply-To: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> X-Enigmail-Version: 1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig87BDB3DE082E4B3619682FC6" X-Virus-Scanned: ClamAV Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches 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, 21 Jul 2011 12:49:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig87BDB3DE082E4B3619682FC6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, > The deadline for making a decision is by the July IETF. If we do not, > our AD has "offered" to make the decision for us! So please take the > time to post your views. I think it would reflect poorly on the WG if w= e > are unable to come to consensus ourselves. During the meeting, I was one of the few persons who raised a hand for the TLV approach. I would like to shortly explain why. First off, of course having existing implementations is good. One for PT-EAP exists in FreeRADIUS, where I came across it. Something strange has happened: even though this implementation was there, people who tried out NEA decided to leave it aside and write a new extension to FreeRADIUS that would evaluate MS-SoH. While SoH is not the same as the TLV approach, it is very similar in that it adds attributes to an existing EAP method. I also got to try out the SoH support in FreeRADIUS and it came very natural, because it provides just yet-another-attribute to evaluate. I came to like that approach; and, to be honest, quickly forgot about the TNC library that would do PT-EAP. Another argument that is being brought up occasionally is that PT-EAP can be forwarded independently of the user authentication. That's undoubtedly true (but one has to pay close attention to protect the forwarding channel, so that NEA data isn't out in clear text!). But I don't really see much use for that - in my view, user authentication and the device the user is using are intrinsically linked together. In a real-life example, yes, one can imagine that a policy "XP SP3 only" exists, and that the NEA policy is offloaded to a different server than the one which handles the authentication. But it is just as easily imaginable that the policy *actually* says in fine-print: "But if it's the CEO's device, don't get in his way even with SP1!" and/or "Only users from the 'Art' department are allowed to bring MACs". That makes for a NEA policy which depends on the user - which would require sending user authentication information along with the NEA data, in order to make a NEA policy decision. I don't think PT-EAP supports piggybacking user-authentication information with NEA data in the PT-EAP datagram - but I may be wrong, of course. I'd appreciate enlightenment :-) The short conclusion of this overly long paragraph is: I think authentication and and NEA evaluation belong together in significant amounts of use cases; so why split them. The third point is a small implementation one: PT-EAP needs many technology prerequisites which are new and not widely deployed in my experience: channel binding, EAP method chaining. It is a significant implementation hurdle to get all that done right. Adding another attribute to an existing RADIUS packet, OTOH, is rather simple, dare I say trivial. I could imagine that NEA uptake in implementations will be higher if the number of hoops to jump through is lower. I'm well aware that my arguments above are not "hard facts" - I just have a better feeling regarding the TLV ones. So, I absolutely don't mind if my concerns get dismissed; but I wanted to raise them nonetheless= =2E Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig87BDB3DE082E4B3619682FC6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4oIFsACgkQ+jm90f8eFWbLnwCginBOUYcQVi5HqP5P9yudZM+5 fFQAn1uP+at+aoXnxtjzZsEiAUY46fra =8r3A -----END PGP SIGNATURE----- --------------enig87BDB3DE082E4B3619682FC6-- From shanna@juniper.net Thu Jul 21 07:27:37 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 6D1E721F8779 for ; Thu, 21 Jul 2011 07:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 Fmdbzwf5zxjK for ; Thu, 21 Jul 2011 07:27:36 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id DC3A321F8757 for ; Thu, 21 Jul 2011 07:27:34 -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 DSNKTig3VvhxRJzr743B+jfQ9Je20jKu6Riv@postini.com; Thu, 21 Jul 2011 07:27:36 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; Thu, 21 Jul 2011 07:27:00 -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; Thu, 21 Jul 2011 10:26:59 -0400 From: Stephen Hanna To: Stefan Winter , "nea@ietf.org" Date: Thu, 21 Jul 2011 10:26:57 -0400 Thread-Topic: [Nea] CALL for COMMENTS on EAP PT approaches Thread-Index: AcxHpKnfTlLzLJpVRlqPBPeAq4SmUwAAuFFQ Message-ID: References: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> <4E282057.5060602@restena.lu> In-Reply-To: <4E282057.5060602@restena.lu> 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 Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches 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, 21 Jul 2011 14:27:37 -0000 Stefan, I really appreciate your comments, especially since they are practical and based on real-world experience, as are my own. One of the good things about NEA is that we've all been solving this problem of endpoint assessmen= t for more than five years with a variety of techniques so we can bring to bear a great deal of experience in what works and what doesn't, as well as what's easy to implement and what's not. I'm not surprised that some people chose to implement SoH support in FreeRADIUS and use that instead of PT-EAP (EAP-TNC). Microsoft includes SoH support in Windows XP SP3, Windows Vista, Windows 7, and Windows Server 2008. That's an awfully large installed base! It's hard to ignore. Most endpoint assessment vendors have implemented some sort of SoH support, in response to customer demand. That doesn't mean we should assume that SoH does everything right. In fact, the folks at Microsoft have supported the NEA effort from the start. They took the lessons learned from SoH (e.g. allow longer messages and multiple round trips) and put them into PB-TNC. You mentioned that SoH makes NEA into just another RADIUS attribute. But none of the proposals here involve putting NEA messages into RADIUS attributes. Instead, the NEA messages will be placed into an EAP tunnel method. That's a good thing, since otherwise the NEA messages could be flying around with little protection (e.g. no confidentiality). In fact, Microsoft uses an EAP tunnel method (PEAP) to carry SoH when it runs over EAP. RADIUS attributes are only used for SoH transport when EAP is not available. So I don't think the idea of stuffing NEA messages into RADIUS attributes is on the table in this discussion. You raised a concern that PT-EAP requires channel binding. Both L2 PT proposals (PT-EAP and EAP-TLV) use TLS channel bindings only when an External Measurement Agent like TPM is used for hardware-based health checks. So there's no difference in the proposals for that. And TLS channel bindings are only used when hardware-based health checks are used. Anyone who's using hardware-based health checks is already in the top .01% of the class in terms of sophistication, at least today. So I wouldn't worry too much that they're going to need to use TLS channel bindings. They're already on the cutting edge of security technology. Anyway, it's the same for both proposals. You make a good point about EAP method chaining. That is fairly new. But I'm not convinced that handling extra TLVs passed in an EAP tunnel method is any less novel. In fact, there has been a lot more work done on analyzing the security properties of EAP method chaining and improving that security than has been done with passing extra TLVs. I'm not aware of any papers that analyze the security of passing extra TLVs in an EAP tunnel method. There might be real security issues there. I appreciate your comments on this. I don't want to dismiss them but rather to take them seriously. We all want to create something here that will be secure and easy to implement and deploy. Your real-world experience is invaluable in that process. Thanks for sharing it. I hope you understand that my comments above are all intended to be constructive and helpful, aiming towards the same goal that you also have. Take care, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Stefan Winter > Sent: Thursday, July 21, 2011 8:49 AM > To: nea@ietf.org > Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches >=20 > Hello, >=20 > > The deadline for making a decision is by the July IETF. If we do not, > > our AD has "offered" to make the decision for us! So please take the > > time to post your views. I think it would reflect poorly on the WG if > we > > are unable to come to consensus ourselves. >=20 > During the meeting, I was one of the few persons who raised a hand for > the TLV approach. I would like to shortly explain why. >=20 > First off, of course having existing implementations is good. One for > PT-EAP exists in FreeRADIUS, where I came across it. Something strange > has happened: even though this implementation was there, people who > tried out NEA decided to leave it aside and write a new extension to > FreeRADIUS that would evaluate MS-SoH. While SoH is not the same as the > TLV approach, it is very similar in that it adds attributes to an > existing EAP method. > I also got to try out the SoH support in FreeRADIUS and it came very > natural, because it provides just yet-another-attribute to evaluate. I > came to like that approach; and, to be honest, quickly forgot about the > TNC library that would do PT-EAP. >=20 > Another argument that is being brought up occasionally is that PT-EAP > can be forwarded independently of the user authentication. That's > undoubtedly true (but one has to pay close attention to protect the > forwarding channel, so that NEA data isn't out in clear text!). But I > don't really see much use for that - in my view, user authentication > and > the device the user is using are intrinsically linked together. In a > real-life example, yes, one can imagine that a policy "XP SP3 only" > exists, and that the NEA policy is offloaded to a different server than > the one which handles the authentication. But it is just as easily > imaginable that the policy *actually* says in fine-print: "But if it's > the CEO's device, don't get in his way even with SP1!" and/or "Only > users from the 'Art' department are allowed to bring MACs". That makes > for a NEA policy which depends on the user - which would require > sending > user authentication information along with the NEA data, in order to > make a NEA policy decision. I don't think PT-EAP supports piggybacking > user-authentication information with NEA data in the PT-EAP datagram - > but I may be wrong, of course. I'd appreciate enlightenment :-) > The short conclusion of this overly long paragraph is: I think > authentication and and NEA evaluation belong together in significant > amounts of use cases; so why split them. >=20 > The third point is a small implementation one: PT-EAP needs many > technology prerequisites which are new and not widely deployed in my > experience: channel binding, EAP method chaining. It is a significant > implementation hurdle to get all that done right. Adding another > attribute to an existing RADIUS packet, OTOH, is rather simple, dare I > say trivial. I could imagine that NEA uptake in implementations will be > higher if the number of hoops to jump through is lower. >=20 > I'm well aware that my arguments above are not "hard facts" - I just > have a better feeling regarding the TLV ones. So, I absolutely don't > mind if my concerns get dismissed; but I wanted to raise them > nonetheless. >=20 > Greetings, >=20 > Stefan Winter >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 From shanna@juniper.net Thu Jul 21 08:02:07 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 2FC2621F8A67 for ; Thu, 21 Jul 2011 08:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 i2fa4NW8A3ag for ; Thu, 21 Jul 2011 08:02:03 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 36A6021F8785 for ; Thu, 21 Jul 2011 08:02:02 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTig/ZVY802/5ph9yPnNZdyHoQ2NRkuni@postini.com; Thu, 21 Jul 2011 08:02:03 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 21 Jul 2011 07:59:01 -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; Thu, 21 Jul 2011 10:58:42 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Thu, 21 Jul 2011 10:58:39 -0400 Thread-Topic: Declaring Consensus to Approve Errata 2848 Against RFC 5793 Thread-Index: Acw1wz3kfWSnByd6SqimotbIl/Y2+gBTYrUQBClPQWA= Message-ID: References: <20110628184311.BB71598C4F4@rfc-editor.org> 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: "turners@ieca.com" , "rfc-editor@rfc-editor.org" , "Ryan.Hurst@microsoft.com" , "andreas.steffen@hsr.ch" Subject: [Nea] Declaring Consensus to Approve Errata 2848 Against RFC 5793 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, 21 Jul 2011 15:02:07 -0000 I saw three comments on the thread started below. All agreed with the errata. Two favored Approving it. One was not sure. Based on this feedback, I declare that there is NEA WG consensus to Approve the errata. I will ask our AD to do so. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Thursday, June 30, 2011 10:49 AM > To: nea@ietf.org > Cc: Ryan.Hurst@microsoft.com; andreas.steffen@hsr.ch; turners@ieca.com; > rfc-editor@rfc-editor.org > Subject: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793 >=20 > I talked with our ADs about how to handle the errata described > below. We agree that the best thing is to have the NEA WG discuss > it and come to a consensus recommendation on the proper resolution. > If the ADs agree, they'll go ahead and implement our recommendation. >=20 > As one of the editors of RFC 5793, I'd say this errata is pretty > obviously correct. The paragraph in question is talking about the > Remediation String. The one occurrence of Reason String in the text > must have been a copy-paste error in the development of the document. >=20 > The other thing to consider is whether the errata should be Approved > (and therefore published in the RFC Editor's errata database) or > marked Hold For Document Update (in which case it's simply set aside > for a future revision of this RFC). The criterion to be used here is > whether the issue "could cause implementation or deployment problems > or significant confusion". This is a tougher call but I'd say that > it could cause implementation or deployment problems. If an implementer > reads the erroneous text at face value, he/she would skip the mandatory > NUL terminator check for Remediation String. That could result in > interoperability problems since a NEA Server that sends a NUL > terminator on the Remediation String would work fine with one > NEA Client but not with another. So I think the errata should be > Approved. >=20 > Do you agree? Let's see some discussion or simply Agree/Disagree > emails so that we can reach consensus. Susan and I plan to close this > discussion in two weeks (end of July 14) so please respond by then. >=20 > BTW, kudos to Andreas for finding and reporting this problem! >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: Tuesday, June 28, 2011 2:43 PM > > To: Ravi.Sahita@intel.com; Stephen Hanna; Ryan.Hurst@microsoft.com; > > kaushik@cisco.com; stephen.farrell@cs.tcd.ie; turners@ieca.com; > > sethomso@cisco.com; Stephen Hanna > > Cc: andreas.steffen@hsr.ch; nea@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC5793 (2848) > > > > > > The following errata report has been submitted for RFC5793, > > "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted > Network > > Connect (TNC)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D5793&eid=3D2848 > > > > -------------------------------------- > > Type: Technical > > Reported by: Andreas Steffen > > > > Section: 4.8.1 > > > > Original Text > > ------------- > > Remediation String (variable length) > > > > > > > > The Remediation String field MUST contain a UTF-8 [6] encoded > > > > string. This string contains human-readable instructions for > > > > remediation that MAY be displayed to the user by the Posture > > > > Broker Client. NUL termination MUST NOT be included. If a > > > > Posture Broker Client receives a Reason String that does > contain > > a > > > > NUL termination, it MUST respond with a fatal Invalid Parameter > > > > error in a CLOSE batch. > > > > > > > > Corrected Text > > -------------- > > Remediation String (variable length) > > > > > > > > The Remediation String field MUST contain a UTF-8 [6] encoded > > > > string. This string contains human-readable instructions for > > > > remediation that MAY be displayed to the user by the Posture > > > > Broker Client. NUL termination MUST NOT be included. If a > > > > Posture Broker Client receives a Remediation String that does > > contain a > > > > NUL termination, it MUST respond with a fatal Invalid Parameter > > > > error in a CLOSE batch. > > > > Notes > > ----- > > Copy-and-paste error: Reason String must be changed to Remediation > > String. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5793 (draft-ietf-nea-pb-tnc-06) > > -------------------------------------- > > Title : PB-TNC: A Posture Broker (PB) Protocol > Compatible > > with Trusted Network Connect (TNC) > > Publication Date : March 2010 > > Author(s) : R. Sahita, S. Hanna, R. Hurst, K. Narayan > > Category : PROPOSED STANDARD > > Source : Network Endpoint Assessment > > Area : Security > > Stream : IETF > > Verifying Party : IESG > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From stephen.farrell@cs.tcd.ie Thu Jul 21 08:10: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 2E1FB21F8A67 for ; Thu, 21 Jul 2011 08:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.849 X-Spam-Level: X-Spam-Status: No, score=-106.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 jXszOoX8C552 for ; Thu, 21 Jul 2011 08:10:12 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id AB85821F86D0 for ; Thu, 21 Jul 2011 08:10:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 90900171C60; Thu, 21 Jul 2011 16:09:49 +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=1311260989; bh=3z/68LhrzGUrqF hiUvulZ4RqaH4H4cF/LlP9reakKHg=; b=Oi2WDe52WjNGRFDUJQBhKSkCJqcWjw D35LH2D+vPBdaz44RvP9MuDzxbJAQsbR81rt+mqHamJ9rveBDFcvN8G+m7tbnb2v YUdxHD7WBG5ftMsooVSkFoDFtNQ9TWKs7jFIJtE6SO33RTjzjjNnXfQ7EIOGTFtO sC3C27d9inahWgwGrA8tIN41BCZjxOzv1e8/TPt+Q1Z5ct3aqZA7H6hIx6asIvDX rGn9UN4xVjbpEW4RktsFvFVJppQiHht4DSa+kSYDh4nYnb9iEI6SUYOk2w5tKXMg pTRV/PKI/NAGM8NVh1BYkVAikIwyaA1EoIrOXbdofAbkrohpCPwzdCQw== 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 HlIn4haIIUGi; Thu, 21 Jul 2011 16:09:49 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6C9DA171CCE; Thu, 21 Jul 2011 16:09:48 +0100 (IST) Message-ID: <4E28413B.6020303@cs.tcd.ie> Date: Thu, 21 Jul 2011 16:09:47 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Stephen Hanna References: <20110628184311.BB71598C4F4@rfc-editor.org> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "turners@ieca.com" , "andreas.steffen@hsr.ch" , "nea@ietf.org" , "Ryan.Hurst@microsoft.com" , "rfc-editor@rfc-editor.org" Subject: Re: [Nea] Declaring Consensus to Approve Errata 2848 Against RFC 5793 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, 21 Jul 2011 15:10:16 -0000 Done. You might want to check I did it right:-) Cheers, S. On 21/07/11 15:58, Stephen Hanna wrote: > I saw three comments on the thread started below. All agreed with the > errata. Two favored Approving it. One was not sure. > > Based on this feedback, I declare that there is NEA WG consensus to > Approve the errata. I will ask our AD to do so. > > Thanks, > > Steve > >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of >> Stephen Hanna >> Sent: Thursday, June 30, 2011 10:49 AM >> To: nea@ietf.org >> Cc: Ryan.Hurst@microsoft.com; andreas.steffen@hsr.ch; turners@ieca.com; >> rfc-editor@rfc-editor.org >> Subject: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793 >> >> I talked with our ADs about how to handle the errata described >> below. We agree that the best thing is to have the NEA WG discuss >> it and come to a consensus recommendation on the proper resolution. >> If the ADs agree, they'll go ahead and implement our recommendation. >> >> As one of the editors of RFC 5793, I'd say this errata is pretty >> obviously correct. The paragraph in question is talking about the >> Remediation String. The one occurrence of Reason String in the text >> must have been a copy-paste error in the development of the document. >> >> The other thing to consider is whether the errata should be Approved >> (and therefore published in the RFC Editor's errata database) or >> marked Hold For Document Update (in which case it's simply set aside >> for a future revision of this RFC). The criterion to be used here is >> whether the issue "could cause implementation or deployment problems >> or significant confusion". This is a tougher call but I'd say that >> it could cause implementation or deployment problems. If an implementer >> reads the erroneous text at face value, he/she would skip the mandatory >> NUL terminator check for Remediation String. That could result in >> interoperability problems since a NEA Server that sends a NUL >> terminator on the Remediation String would work fine with one >> NEA Client but not with another. So I think the errata should be >> Approved. >> >> Do you agree? Let's see some discussion or simply Agree/Disagree >> emails so that we can reach consensus. Susan and I plan to close this >> discussion in two weeks (end of July 14) so please respond by then. >> >> BTW, kudos to Andreas for finding and reporting this problem! >> >> Thanks, >> >> Steve >> >>> -----Original Message----- >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>> Sent: Tuesday, June 28, 2011 2:43 PM >>> To: Ravi.Sahita@intel.com; Stephen Hanna; Ryan.Hurst@microsoft.com; >>> kaushik@cisco.com; stephen.farrell@cs.tcd.ie; turners@ieca.com; >>> sethomso@cisco.com; Stephen Hanna >>> Cc: andreas.steffen@hsr.ch; nea@ietf.org; rfc-editor@rfc-editor.org >>> Subject: [Technical Errata Reported] RFC5793 (2848) >>> >>> >>> The following errata report has been submitted for RFC5793, >>> "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted >> Network >>> Connect (TNC)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=5793&eid=2848 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Andreas Steffen >>> >>> Section: 4.8.1 >>> >>> Original Text >>> ------------- >>> Remediation String (variable length) >>> >>> >>> >>> The Remediation String field MUST contain a UTF-8 [6] encoded >>> >>> string. This string contains human-readable instructions for >>> >>> remediation that MAY be displayed to the user by the Posture >>> >>> Broker Client. NUL termination MUST NOT be included. If a >>> >>> Posture Broker Client receives a Reason String that does >> contain >>> a >>> >>> NUL termination, it MUST respond with a fatal Invalid Parameter >>> >>> error in a CLOSE batch. >>> >>> >>> >>> Corrected Text >>> -------------- >>> Remediation String (variable length) >>> >>> >>> >>> The Remediation String field MUST contain a UTF-8 [6] encoded >>> >>> string. This string contains human-readable instructions for >>> >>> remediation that MAY be displayed to the user by the Posture >>> >>> Broker Client. NUL termination MUST NOT be included. If a >>> >>> Posture Broker Client receives a Remediation String that does >>> contain a >>> >>> NUL termination, it MUST respond with a fatal Invalid Parameter >>> >>> error in a CLOSE batch. >>> >>> Notes >>> ----- >>> Copy-and-paste error: Reason String must be changed to Remediation >>> String. >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC5793 (draft-ietf-nea-pb-tnc-06) >>> -------------------------------------- >>> Title : PB-TNC: A Posture Broker (PB) Protocol >> Compatible >>> with Trusted Network Connect (TNC) >>> Publication Date : March 2010 >>> Author(s) : R. Sahita, S. Hanna, R. Hurst, K. Narayan >>> Category : PROPOSED STANDARD >>> Source : Network Endpoint Assessment >>> Area : Security >>> Stream : IETF >>> Verifying Party : IESG >> _______________________________________________ >> 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 shanna@juniper.net Thu Jul 21 08:14:12 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 3236221F86C3 for ; Thu, 21 Jul 2011 08:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 rB2VNyszHdYo for ; Thu, 21 Jul 2011 08:14:08 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id 865E221F86AC for ; Thu, 21 Jul 2011 08:14:07 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTihCOc3lIN0zh7EeIxSwJdxfp4jEvadQ@postini.com; Thu, 21 Jul 2011 08:14:07 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 21 Jul 2011 08:11:38 -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; Thu, 21 Jul 2011 11:11:37 -0400 From: Stephen Hanna To: Stephen Farrell Date: Thu, 21 Jul 2011 11:11:35 -0400 Thread-Topic: [Nea] Declaring Consensus to Approve Errata 2848 Against RFC 5793 Thread-Index: AcxHuD4FDtzTV3pNSiabh/tKtPjXsAAACu3Q Message-ID: References: <20110628184311.BB71598C4F4@rfc-editor.org> <4E28413B.6020303@cs.tcd.ie> In-Reply-To: <4E28413B.6020303@cs.tcd.ie> 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: "turners@ieca.com" , "andreas.steffen@hsr.ch" , "nea@ietf.org" , "Ryan.Hurst@microsoft.com" , "rfc-editor@rfc-editor.org" Subject: Re: [Nea] Declaring Consensus to Approve Errata 2848 Against RFC 5793 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, 21 Jul 2011 15:14:12 -0000 Everything looks good to me. Let's consider this done. Thanks, Steve > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, July 21, 2011 11:10 AM > To: Stephen Hanna > Cc: nea@ietf.org; turners@ieca.com; rfc-editor@rfc-editor.org; > Ryan.Hurst@microsoft.com; andreas.steffen@hsr.ch > Subject: Re: [Nea] Declaring Consensus to Approve Errata 2848 Against > RFC 5793 >=20 >=20 > Done. You might want to check I did it right:-) > Cheers, > S. >=20 > On 21/07/11 15:58, Stephen Hanna wrote: > > I saw three comments on the thread started below. All agreed with the > > errata. Two favored Approving it. One was not sure. > > > > Based on this feedback, I declare that there is NEA WG consensus to > > Approve the errata. I will ask our AD to do so. > > > > Thanks, > > > > Steve > > > >> -----Original Message----- > >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf > Of > >> Stephen Hanna > >> Sent: Thursday, June 30, 2011 10:49 AM > >> To: nea@ietf.org > >> Cc: Ryan.Hurst@microsoft.com; andreas.steffen@hsr.ch; > turners@ieca.com; > >> rfc-editor@rfc-editor.org > >> Subject: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793 > >> > >> I talked with our ADs about how to handle the errata described > >> below. We agree that the best thing is to have the NEA WG discuss > >> it and come to a consensus recommendation on the proper resolution. > >> If the ADs agree, they'll go ahead and implement our recommendation. > >> > >> As one of the editors of RFC 5793, I'd say this errata is pretty > >> obviously correct. The paragraph in question is talking about the > >> Remediation String. The one occurrence of Reason String in the text > >> must have been a copy-paste error in the development of the > document. > >> > >> The other thing to consider is whether the errata should be Approved > >> (and therefore published in the RFC Editor's errata database) or > >> marked Hold For Document Update (in which case it's simply set aside > >> for a future revision of this RFC). The criterion to be used here is > >> whether the issue "could cause implementation or deployment problems > >> or significant confusion". This is a tougher call but I'd say that > >> it could cause implementation or deployment problems. If an > implementer > >> reads the erroneous text at face value, he/she would skip the > mandatory > >> NUL terminator check for Remediation String. That could result in > >> interoperability problems since a NEA Server that sends a NUL > >> terminator on the Remediation String would work fine with one > >> NEA Client but not with another. So I think the errata should be > >> Approved. > >> > >> Do you agree? Let's see some discussion or simply Agree/Disagree > >> emails so that we can reach consensus. Susan and I plan to close > this > >> discussion in two weeks (end of July 14) so please respond by then. > >> > >> BTW, kudos to Andreas for finding and reporting this problem! > >> > >> Thanks, > >> > >> Steve > >> > >>> -----Original Message----- > >>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > >>> Sent: Tuesday, June 28, 2011 2:43 PM > >>> To: Ravi.Sahita@intel.com; Stephen Hanna; Ryan.Hurst@microsoft.com; > >>> kaushik@cisco.com; stephen.farrell@cs.tcd.ie; turners@ieca.com; > >>> sethomso@cisco.com; Stephen Hanna > >>> Cc: andreas.steffen@hsr.ch; nea@ietf.org; rfc-editor@rfc-editor.org > >>> Subject: [Technical Errata Reported] RFC5793 (2848) > >>> > >>> > >>> The following errata report has been submitted for RFC5793, > >>> "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted > >> Network > >>> Connect (TNC)". > >>> > >>> -------------------------------------- > >>> You may review the report below and at: > >>> http://www.rfc-editor.org/errata_search.php?rfc=3D5793&eid=3D2848 > >>> > >>> -------------------------------------- > >>> Type: Technical > >>> Reported by: Andreas Steffen > >>> > >>> Section: 4.8.1 > >>> > >>> Original Text > >>> ------------- > >>> Remediation String (variable length) > >>> > >>> > >>> > >>> The Remediation String field MUST contain a UTF-8 [6] encoded > >>> > >>> string. This string contains human-readable instructions for > >>> > >>> remediation that MAY be displayed to the user by the Posture > >>> > >>> Broker Client. NUL termination MUST NOT be included. If a > >>> > >>> Posture Broker Client receives a Reason String that does > >> contain > >>> a > >>> > >>> NUL termination, it MUST respond with a fatal Invalid > Parameter > >>> > >>> error in a CLOSE batch. > >>> > >>> > >>> > >>> Corrected Text > >>> -------------- > >>> Remediation String (variable length) > >>> > >>> > >>> > >>> The Remediation String field MUST contain a UTF-8 [6] encoded > >>> > >>> string. This string contains human-readable instructions for > >>> > >>> remediation that MAY be displayed to the user by the Posture > >>> > >>> Broker Client. NUL termination MUST NOT be included. If a > >>> > >>> Posture Broker Client receives a Remediation String that does > >>> contain a > >>> > >>> NUL termination, it MUST respond with a fatal Invalid > Parameter > >>> > >>> error in a CLOSE batch. > >>> > >>> Notes > >>> ----- > >>> Copy-and-paste error: Reason String must be changed to Remediation > >>> String. > >>> > >>> Instructions: > >>> ------------- > >>> This errata is currently posted as "Reported". If necessary, please > >>> use "Reply All" to discuss whether it should be verified or > >>> rejected. When a decision is reached, the verifying party (IESG) > >>> can log in to change the status and edit the report, if necessary. > >>> > >>> -------------------------------------- > >>> RFC5793 (draft-ietf-nea-pb-tnc-06) > >>> -------------------------------------- > >>> Title : PB-TNC: A Posture Broker (PB) Protocol > >> Compatible > >>> with Trusted Network Connect (TNC) > >>> Publication Date : March 2010 > >>> Author(s) : R. Sahita, S. Hanna, R. Hurst, K. Narayan > >>> Category : PROPOSED STANDARD > >>> Source : Network Endpoint Assessment > >>> Area : Security > >>> Stream : IETF > >>> Verifying Party : IESG > >> _______________________________________________ > >> 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 Thu Jul 21 20:57: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 7976811E8079 for ; Thu, 21 Jul 2011 20:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.456 X-Spam-Level: X-Spam-Status: No, score=-105.456 tagged_above=-999 required=5 tests=[AWL=-2.857, 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 cE4KpuvNKQkW for ; Thu, 21 Jul 2011 20:57:22 -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 A3F5211E8075 for ; Thu, 21 Jul 2011 20:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=3104; q=dns/txt; s=iport; t=1311307042; x=1312516642; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=xdThqLSI/ZMHbJG+0w+sNVt+/gFZkYW9ED+vrAzyR30=; b=dxIVuK+oCyv+Qsuz0sq6Ok9Ai5tA3/3fdVfp9JkSV7XLDxDyqAkb6gvk a2Ou1WyOuF6pmzguUXWFulOyELTeufGPe82MioymklQvGkqC1pNWlv3wI VCRCw97SgHYaWblrQNiz2iQG0KAeu0/1yrVzTx8gVEfVZJhDBxLxJkrYs Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AALn0KE6rRDoH/2dsb2JhbABTl3WPTHeIfJ9dnhyFYF8Eh1WLGYUHi3c X-IronPort-AV: E=Sophos;i="4.67,245,1309737600"; d="scan'208";a="5347224" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-5.cisco.com with ESMTP; 22 Jul 2011 03:57:22 +0000 Received: from [10.33.251.182] ([10.33.251.182]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p6M3vK9b014366; Fri, 22 Jul 2011 03:57:21 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <189716C74BBB9C4095FE8CA503B1FC3A5525C6A885@EMBX02-HQ.jnpr.net> Date: Thu, 21 Jul 2011 20:57:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> <189716C74BBB9C4095FE8CA503B1FC3A5525C6A885@EMBX02-HQ.jnpr.net> To: Lisa Lorenzin X-Mailer: Apple Mail (2.1084) Cc: "nea@ietf.org" Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches 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, 22 Jul 2011 03:57:23 -0000 I'm still concerned that many implementations may not support EAP = chaining. I've been searching online trying to find out how current = PT-EAP implementations support client authentication. I haven't had = much luck. Can someone point me to some documentation that explains = what sort of client authentication the current implementations support?=20= Thanks, Joe On Jul 12, 2011, at 11:24 AM, Lisa Lorenzin wrote: > Greetings! >=20 > Based on the meeting minutes and previous discussion thread, > it looks to me like a) there are pros and cons to each > approach, and b) either approach would accomplish the > technical goals. >=20 > In the absence of a clear technical front-runner, layer 8 > considerations take on greater significance. Since PT-EAP > has many more technical implementations, and is based on > an open standard from TCG, it seems to better conform to > the IETF's emphasis on running code, and to better comply > with the RFC 5209 requirement to "prefer the reuse of > existing open standards that meet the requirements before > defining new ones." >=20 > Based on those considerations, PT-EAP seems like a better > choice. >=20 > Regards, >=20 > Lisa >=20 >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On >> Behalf Of Susan Thomson (sethomso) >> Sent: Thursday, June 30, 2011 18:31 >> To: nea@ietf.org >> Subject: [Nea] CALL for COMMENTS on EAP PT approaches >>=20 >> One of the outstanding items in the NEA WG is to come to consensus on >> whether to use EAP method or TLV for carrying NEA data in an = EAP-based >> transport. >>=20 >> Steve Hanna has initiated a thread on this topic on the >> mailing list to >> which some have responded (see pointer below to email thread and to >> meeting minutes for summary of discussion at IETF 80). >>=20 >> We need more input from the WG to make a decision. Please review the >> pros and cons laid out in the thread and provide your input. Feedback >> may include any considerations that you think might be >> missing from the >> discussion, as well how you would weigh the characteristics of the = two >> approaches. >>=20 >> The deadline for making a decision is by the July IETF. If we do not, >> our AD has "offered" to make the decision for us! So please take the >> time to post your views. I think it would reflect poorly on >> the WG if we >> are unable to come to consensus ourselves. >>=20 >> Thanks >> Susan >>=20 >> Email Thread starts here: >> http://www.ietf.org/mail-archive/web/nea/current/msg01120.html >>=20 >> Meeting minutes from IETF 80: >> http://tools.ietf.org/wg/nea/minutes?item=3Dminutes80.html >>=20 >>=20 >> _______________________________________________ >> 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 andreas.steffen@strongswan.org Thu Jul 21 21:51:38 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 DD50821F8725 for ; Thu, 21 Jul 2011 21:51:38 -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 kwseUdGfXEaI for ; Thu, 21 Jul 2011 21:51:38 -0700 (PDT) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by ietfa.amsl.com (Postfix) with ESMTP id DE21121F85C6 for ; Thu, 21 Jul 2011 21:51:37 -0700 (PDT) Received: from 84-74-90-103.dclient.hispeed.ch ([84.74.90.103]) by strongswan.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1Qk7ho-0001U0-5y; Fri, 22 Jul 2011 06:51:20 +0200 Message-ID: <4E2901D1.70608@strongswan.org> Date: Fri, 22 Jul 2011 06:51:29 +0200 From: Andreas Steffen User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: Joe Salowey References: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> <189716C74BBB9C4095FE8CA503B1FC3A5525C6A885@EMBX02-HQ.jnpr.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nea@ietf.org" Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches 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, 22 Jul 2011 04:51:39 -0000 Hello Joe, strongSwan either uses certificate-based EAP-TLS client authentication while setting up the outer EAP-TTLS tunnel that protects the PT-EAP channel: http://www.strongswan.org/uml/testresults45rc/tnc/tnccs-20-tls/carol.daemon.log or uses the chain of EAP-Identity, followed by EAP-MD5/MSCHAPv2/GTC, followed by PT-EAP within the outer EAP-TTLS tunnel: http://www.strongswan.org/uml/testresults45rc/tnc/tnccs-20/carol.daemon.log Regards Andreas On 07/22/2011 05:57 AM, Joe Salowey wrote: > I'm still concerned that many implementations may not support EAP > chaining. I've been searching online trying to find out how current > PT-EAP implementations support client authentication. I haven't had > much luck. Can someone point me to some documentation that explains > what sort of client authentication the current implementations > support? > > Thanks, > > Joe On Jul 12, 2011, at 11:24 AM, Lisa Lorenzin wrote: > >> Greetings! >> >> Based on the meeting minutes and previous discussion thread, it >> looks to me like a) there are pros and cons to each approach, and >> b) either approach would accomplish the technical goals. >> >> In the absence of a clear technical front-runner, layer 8 >> considerations take on greater significance. Since PT-EAP has many >> more technical implementations, and is based on an open standard >> from TCG, it seems to better conform to the IETF's emphasis on >> running code, and to better comply with the RFC 5209 requirement to >> "prefer the reuse of existing open standards that meet the >> requirements before defining new ones." >> >> Based on those considerations, PT-EAP seems like a better choice. >> >> Regards, >> >> Lisa >> >>> -----Original Message----- From: nea-bounces@ietf.org >>> [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson >>> (sethomso) Sent: Thursday, June 30, 2011 18:31 To: nea@ietf.org >>> Subject: [Nea] CALL for COMMENTS on EAP PT approaches >>> >>> One of the outstanding items in the NEA WG is to come to >>> consensus on whether to use EAP method or TLV for carrying NEA >>> data in an EAP-based transport. >>> >>> Steve Hanna has initiated a thread on this topic on the mailing >>> list to which some have responded (see pointer below to email >>> thread and to meeting minutes for summary of discussion at IETF >>> 80). >>> >>> We need more input from the WG to make a decision. Please review >>> the pros and cons laid out in the thread and provide your input. >>> Feedback may include any considerations that you think might be >>> missing from the discussion, as well how you would weigh the >>> characteristics of the two approaches. >>> >>> The deadline for making a decision is by the July IETF. If we do >>> not, our AD has "offered" to make the decision for us! So please >>> take the time to post your views. I think it would reflect poorly >>> on the WG if we are unable to come to consensus ourselves. >>> >>> Thanks Susan >>> >>> Email Thread starts here: >>> http://www.ietf.org/mail-archive/web/nea/current/msg01120.html >>> >>> Meeting minutes from IETF 80: >>> http://tools.ietf.org/wg/nea/minutes?item=minutes80.html ====================================================================== 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 stefan.winter@restena.lu Fri Jul 22 05:57: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 2420B21F87C3 for ; Fri, 22 Jul 2011 05:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 FOL8Xl6oEQKG for ; Fri, 22 Jul 2011 05:57:20 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id B836821F8784 for ; Fri, 22 Jul 2011 05:57:19 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7CD8910584; Fri, 22 Jul 2011 14:57:18 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 6078F10582; Fri, 22 Jul 2011 14:57:18 +0200 (CEST) Message-ID: <4E2973AF.8000208@restena.lu> Date: Fri, 22 Jul 2011 14:57:19 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Stephen Hanna References: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> <4E282057.5060602@restena.lu> In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0FA8EBE90BE161779635CBF4" X-Virus-Scanned: ClamAV Cc: "nea@ietf.org" Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches 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, 22 Jul 2011 12:57:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0FA8EBE90BE161779635CBF4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello Steve, all, thanks for these explanations, they are very helpful. Could you bear with me one more time, please? It's about the one comment that your reply didn't touch upon: Assume the authentication server and NEA server are separate entities, and that the assessment result of a machine varies depending in the user's identity (say, management is allowed to drag behind one Windows Service Pack; or that certain machine types are only tolerated for some user groups). In that case, the NEA server needs to make different assessments dependent on the user identity. Since it is not co-located with the authentication server, PT-EAP needs to be forwarded to the NEA server. How does the user identity information get to the NEA server, so that he can make his assessment? Is it possible to blend parts of the preceeding EAP (authentication) into the contents of the PT-EAP? In particular, the information that is to be blended in would be the inner identity as it was verified by the preceeding EAP method. Greetings, Stefan Winter Am 21.07.2011 16:26, schrieb Stephen Hanna: > Stefan, > > I really appreciate your comments, especially since they are practical > and based on real-world experience, as are my own. One of the good thin= gs > about NEA is that we've all been solving this problem of endpoint asses= sment > for more than five years with a variety of techniques so we can bring t= o > bear a great deal of experience in what works and what doesn't, as well= as > what's easy to implement and what's not. > > I'm not surprised that some people chose to implement SoH support in > FreeRADIUS and use that instead of PT-EAP (EAP-TNC). Microsoft includes= > SoH support in Windows XP SP3, Windows Vista, Windows 7, and Windows > Server 2008. That's an awfully large installed base! It's hard to ignor= e. > Most endpoint assessment vendors have implemented some sort of SoH > support, in response to customer demand. That doesn't mean we should > assume that SoH does everything right. In fact, the folks at Microsoft > have supported the NEA effort from the start. They took the lessons > learned from SoH (e.g. allow longer messages and multiple round trips) > and put them into PB-TNC. > > You mentioned that SoH makes NEA into just another RADIUS attribute. > But none of the proposals here involve putting NEA messages into > RADIUS attributes. Instead, the NEA messages will be placed into an > EAP tunnel method. That's a good thing, since otherwise the NEA message= s > could be flying around with little protection (e.g. no confidentiality)= =2E > In fact, Microsoft uses an EAP tunnel method (PEAP) to carry SoH when > it runs over EAP. RADIUS attributes are only used for SoH transport whe= n > EAP is not available. So I don't think the idea of stuffing NEA message= s > into RADIUS attributes is on the table in this discussion. > > You raised a concern that PT-EAP requires channel binding. Both L2 > PT proposals (PT-EAP and EAP-TLV) use TLS channel bindings only when > an External Measurement Agent like TPM is used for hardware-based > health checks. So there's no difference in the proposals for that. > And TLS channel bindings are only used when hardware-based health > checks are used. Anyone who's using hardware-based health checks is > already in the top .01% of the class in terms of sophistication, > at least today. So I wouldn't worry too much that they're going to > need to use TLS channel bindings. They're already on the cutting > edge of security technology. Anyway, it's the same for both proposals. > > You make a good point about EAP method chaining. That is fairly new. > But I'm not convinced that handling extra TLVs passed in an EAP > tunnel method is any less novel. In fact, there has been a lot more > work done on analyzing the security properties of EAP method chaining > and improving that security than has been done with passing extra TLVs.= > I'm not aware of any papers that analyze the security of passing extra > TLVs in an EAP tunnel method. There might be real security issues there= =2E > > I appreciate your comments on this. I don't want to dismiss them > but rather to take them seriously. We all want to create something > here that will be secure and easy to implement and deploy. Your > real-world experience is invaluable in that process. Thanks for > sharing it. I hope you understand that my comments above are all > intended to be constructive and helpful, aiming towards the same > goal that you also have. > > Take care, > > Steve > >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of >> Stefan Winter >> Sent: Thursday, July 21, 2011 8:49 AM >> To: nea@ietf.org >> Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches >> >> Hello, >> >>> The deadline for making a decision is by the July IETF. If we do not,= >>> our AD has "offered" to make the decision for us! So please take the >>> time to post your views. I think it would reflect poorly on the WG if= >> we >>> are unable to come to consensus ourselves. >> During the meeting, I was one of the few persons who raised a hand for= >> the TLV approach. I would like to shortly explain why. >> >> First off, of course having existing implementations is good. One for >> PT-EAP exists in FreeRADIUS, where I came across it. Something strange= >> has happened: even though this implementation was there, people who >> tried out NEA decided to leave it aside and write a new extension to >> FreeRADIUS that would evaluate MS-SoH. While SoH is not the same as th= e >> TLV approach, it is very similar in that it adds attributes to an >> existing EAP method. >> I also got to try out the SoH support in FreeRADIUS and it came very >> natural, because it provides just yet-another-attribute to evaluate. I= >> came to like that approach; and, to be honest, quickly forgot about th= e >> TNC library that would do PT-EAP. >> >> Another argument that is being brought up occasionally is that PT-EAP >> can be forwarded independently of the user authentication. That's >> undoubtedly true (but one has to pay close attention to protect the >> forwarding channel, so that NEA data isn't out in clear text!). But I >> don't really see much use for that - in my view, user authentication >> and >> the device the user is using are intrinsically linked together. In a >> real-life example, yes, one can imagine that a policy "XP SP3 only" >> exists, and that the NEA policy is offloaded to a different server tha= n >> the one which handles the authentication. But it is just as easily >> imaginable that the policy *actually* says in fine-print: "But if it's= >> the CEO's device, don't get in his way even with SP1!" and/or "Only >> users from the 'Art' department are allowed to bring MACs". That makes= >> for a NEA policy which depends on the user - which would require >> sending >> user authentication information along with the NEA data, in order to >> make a NEA policy decision. I don't think PT-EAP supports piggybacking= >> user-authentication information with NEA data in the PT-EAP datagram -= >> but I may be wrong, of course. I'd appreciate enlightenment :-) >> The short conclusion of this overly long paragraph is: I think >> authentication and and NEA evaluation belong together in significant >> amounts of use cases; so why split them. >> >> The third point is a small implementation one: PT-EAP needs many >> technology prerequisites which are new and not widely deployed in my >> experience: channel binding, EAP method chaining. It is a significant >> implementation hurdle to get all that done right. Adding another >> attribute to an existing RADIUS packet, OTOH, is rather simple, dare I= >> say trivial. I could imagine that NEA uptake in implementations will b= e >> higher if the number of hoops to jump through is lower. >> >> I'm well aware that my arguments above are not "hard facts" - I just >> have a better feeling regarding the TLV ones. So, I absolutely don't >> mind if my concerns get dismissed; but I wanted to raise them >> nonetheless. >> >> Greetings, >> >> Stefan Winter >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et >> de la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >> --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig0FA8EBE90BE161779635CBF4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4pc68ACgkQ+jm90f8eFWbKFQCeMxK0jYkVUtNCvcuNMrsE3tGu klAAnjB3B35a5+X0c8NHkJzwtqTSaZPd =43vn -----END PGP SIGNATURE----- --------------enig0FA8EBE90BE161779635CBF4-- From shanna@juniper.net Fri Jul 22 07:47: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 4A6FC21F8AF3 for ; Fri, 22 Jul 2011 07:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 8YyRcB1BWJUA for ; Fri, 22 Jul 2011 07:47:10 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id DD8CF21F8B12 for ; Fri, 22 Jul 2011 07:47:07 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKTimNa5d0ZkpnVWQPrRXTGIOT7xUQ3c2o@postini.com; Fri, 22 Jul 2011 07:47:09 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, 22 Jul 2011 07:46:13 -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, 22 Jul 2011 10:46:13 -0400 From: Stephen Hanna To: Stefan Winter Date: Fri, 22 Jul 2011 10:46:10 -0400 Thread-Topic: [Nea] CALL for COMMENTS on EAP PT approaches Thread-Index: AcxIbuW5E7AcCrfITL2wDt9HhGA04gAAnLWA Message-ID: References: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> <4E282057.5060602@restena.lu> <4E2973AF.8000208@restena.lu> In-Reply-To: <4E2973AF.8000208@restena.lu> 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] CALL for COMMENTS on EAP PT approaches 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, 22 Jul 2011 14:47:11 -0000 Stefan, I don't know of any standard way to provide information about identity from the authentication server to the NEA server. I suppose that a standard RADIUS attribute could be defined to carry this information, something like the IF-FTNC-User-Name-Identifier attribute defined in the Federated TNC specification published at http://www.trustedcomputinggroup.org/resources/federated_tnc_version_10_rev= ision_26 However, that attribute was not defined for this exact use case and I wouldn't propose that anything be done about this now. We have to finish our work on the basic NEA specifications and this problem is not part of our agreed-upon use cases for NEA. I'd say that if you have placed your authentication server and your NEA server on separate machines, you have effectively separated the functions of authentication and posture checking. Still, the authentication server could have a policy that says that because of the user's identity or role, a failed posture check should not block network access for that user. That's not unusual. But I don't think there's any standard way when the authentication server and the NEA server are separated in this manner to convey user identity to the NEA server, at least not at this point. If you want to perform different health checks depending on identity, you should use a NEA server that's integrated with the authentication server. Thanks, Steve > -----Original Message----- > From: Stefan Winter [mailto:stefan.winter@restena.lu] > Sent: Friday, July 22, 2011 8:57 AM > To: Stephen Hanna > Cc: nea@ietf.org > Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches >=20 > Hello Steve, all, >=20 > thanks for these explanations, they are very helpful. >=20 > Could you bear with me one more time, please? It's about the one > comment > that your reply didn't touch upon: Assume the authentication server and > NEA server are separate entities, and that the assessment result of a > machine varies depending in the user's identity (say, management is > allowed to drag behind one Windows Service Pack; or that certain > machine > types are only tolerated for some user groups). >=20 > In that case, the NEA server needs to make different assessments > dependent on the user identity. Since it is not co-located with the > authentication server, PT-EAP needs to be forwarded to the NEA server. > How does the user identity information get to the NEA server, so that > he > can make his assessment? Is it possible to blend parts of the > preceeding > EAP (authentication) into the contents of the PT-EAP? >=20 > In particular, the information that is to be blended in would be the > inner identity as it was verified by the preceeding EAP method. >=20 > Greetings, >=20 > Stefan Winter >=20 > Am 21.07.2011 16:26, schrieb Stephen Hanna: > > Stefan, > > > > I really appreciate your comments, especially since they are > practical > > and based on real-world experience, as are my own. One of the good > things > > about NEA is that we've all been solving this problem of endpoint > assessment > > for more than five years with a variety of techniques so we can bring > to > > bear a great deal of experience in what works and what doesn't, as > well as > > what's easy to implement and what's not. > > > > I'm not surprised that some people chose to implement SoH support in > > FreeRADIUS and use that instead of PT-EAP (EAP-TNC). Microsoft > includes > > SoH support in Windows XP SP3, Windows Vista, Windows 7, and Windows > > Server 2008. That's an awfully large installed base! It's hard to > ignore. > > Most endpoint assessment vendors have implemented some sort of SoH > > support, in response to customer demand. That doesn't mean we should > > assume that SoH does everything right. In fact, the folks at > Microsoft > > have supported the NEA effort from the start. They took the lessons > > learned from SoH (e.g. allow longer messages and multiple round > trips) > > and put them into PB-TNC. > > > > You mentioned that SoH makes NEA into just another RADIUS attribute. > > But none of the proposals here involve putting NEA messages into > > RADIUS attributes. Instead, the NEA messages will be placed into an > > EAP tunnel method. That's a good thing, since otherwise the NEA > messages > > could be flying around with little protection (e.g. no > confidentiality). > > In fact, Microsoft uses an EAP tunnel method (PEAP) to carry SoH when > > it runs over EAP. RADIUS attributes are only used for SoH transport > when > > EAP is not available. So I don't think the idea of stuffing NEA > messages > > into RADIUS attributes is on the table in this discussion. > > > > You raised a concern that PT-EAP requires channel binding. Both L2 > > PT proposals (PT-EAP and EAP-TLV) use TLS channel bindings only when > > an External Measurement Agent like TPM is used for hardware-based > > health checks. So there's no difference in the proposals for that. > > And TLS channel bindings are only used when hardware-based health > > checks are used. Anyone who's using hardware-based health checks is > > already in the top .01% of the class in terms of sophistication, > > at least today. So I wouldn't worry too much that they're going to > > need to use TLS channel bindings. They're already on the cutting > > edge of security technology. Anyway, it's the same for both > proposals. > > > > You make a good point about EAP method chaining. That is fairly new. > > But I'm not convinced that handling extra TLVs passed in an EAP > > tunnel method is any less novel. In fact, there has been a lot more > > work done on analyzing the security properties of EAP method chaining > > and improving that security than has been done with passing extra > TLVs. > > I'm not aware of any papers that analyze the security of passing > extra > > TLVs in an EAP tunnel method. There might be real security issues > there. > > > > I appreciate your comments on this. I don't want to dismiss them > > but rather to take them seriously. We all want to create something > > here that will be secure and easy to implement and deploy. Your > > real-world experience is invaluable in that process. Thanks for > > sharing it. I hope you understand that my comments above are all > > intended to be constructive and helpful, aiming towards the same > > goal that you also have. > > > > Take care, > > > > Steve > > > >> -----Original Message----- > >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf > Of > >> Stefan Winter > >> Sent: Thursday, July 21, 2011 8:49 AM > >> To: nea@ietf.org > >> Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches > >> > >> Hello, > >> > >>> The deadline for making a decision is by the July IETF. If we do > not, > >>> our AD has "offered" to make the decision for us! So please take > the > >>> time to post your views. I think it would reflect poorly on the WG > if > >> we > >>> are unable to come to consensus ourselves. > >> During the meeting, I was one of the few persons who raised a hand > for > >> the TLV approach. I would like to shortly explain why. > >> > >> First off, of course having existing implementations is good. One > for > >> PT-EAP exists in FreeRADIUS, where I came across it. Something > strange > >> has happened: even though this implementation was there, people who > >> tried out NEA decided to leave it aside and write a new extension to > >> FreeRADIUS that would evaluate MS-SoH. While SoH is not the same as > the > >> TLV approach, it is very similar in that it adds attributes to an > >> existing EAP method. > >> I also got to try out the SoH support in FreeRADIUS and it came very > >> natural, because it provides just yet-another-attribute to evaluate. > I > >> came to like that approach; and, to be honest, quickly forgot about > the > >> TNC library that would do PT-EAP. > >> > >> Another argument that is being brought up occasionally is that PT- > EAP > >> can be forwarded independently of the user authentication. That's > >> undoubtedly true (but one has to pay close attention to protect the > >> forwarding channel, so that NEA data isn't out in clear text!). But > I > >> don't really see much use for that - in my view, user authentication > >> and > >> the device the user is using are intrinsically linked together. In a > >> real-life example, yes, one can imagine that a policy "XP SP3 only" > >> exists, and that the NEA policy is offloaded to a different server > than > >> the one which handles the authentication. But it is just as easily > >> imaginable that the policy *actually* says in fine-print: "But if > it's > >> the CEO's device, don't get in his way even with SP1!" and/or "Only > >> users from the 'Art' department are allowed to bring MACs". That > makes > >> for a NEA policy which depends on the user - which would require > >> sending > >> user authentication information along with the NEA data, in order to > >> make a NEA policy decision. I don't think PT-EAP supports > piggybacking > >> user-authentication information with NEA data in the PT-EAP datagram > - > >> but I may be wrong, of course. I'd appreciate enlightenment :-) > >> The short conclusion of this overly long paragraph is: I think > >> authentication and and NEA evaluation belong together in significant > >> amounts of use cases; so why split them. > >> > >> The third point is a small implementation one: PT-EAP needs many > >> technology prerequisites which are new and not widely deployed in my > >> experience: channel binding, EAP method chaining. It is a > significant > >> implementation hurdle to get all that done right. Adding another > >> attribute to an existing RADIUS packet, OTOH, is rather simple, dare > I > >> say trivial. I could imagine that NEA uptake in implementations will > be > >> higher if the number of hoops to jump through is lower. > >> > >> I'm well aware that my arguments above are not "hard facts" - I just > >> have a better feeling regarding the TLV ones. So, I absolutely don't > >> mind if my concerns get dismissed; but I wanted to raise them > >> nonetheless. > >> > >> Greetings, > >> > >> Stefan Winter > >> > >> -- > >> Stefan WINTER > >> Ingenieur de Recherche > >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale > et > >> de la Recherche > >> 6, rue Richard Coudenhove-Kalergi > >> L-1359 Luxembourg > >> > >> Tel: +352 424409 1 > >> Fax: +352 422473 > >> >=20 >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 From shanna@juniper.net Fri Jul 22 08:27: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 880DF21F8510 for ; Fri, 22 Jul 2011 08:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 RwPgUT8QMsuY for ; Fri, 22 Jul 2011 08:27:15 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id D2C9621F854D for ; Fri, 22 Jul 2011 08:27:14 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTimW0htCjF0BNDixna/FOQPMoGhlwhKJ@postini.com; Fri, 22 Jul 2011 08:27:15 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; Fri, 22 Jul 2011 08:25:53 -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; Fri, 22 Jul 2011 11:25:52 -0400 From: Stephen Hanna To: Joe Salowey Date: Fri, 22 Jul 2011 11:25:50 -0400 Thread-Topic: [Nea] CALL for COMMENTS on EAP PT approaches Thread-Index: AcxIKxsSMRkaAhAfSiesdK4+83U+kAAVJv4A Message-ID: References: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> <189716C74BBB9C4095FE8CA503B1FC3A5525C6A885@EMBX02-HQ.jnpr.net> <4E2901D1.70608@strongswan.org> In-Reply-To: <4E2901D1.70608@strongswan.org> 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] CALL for COMMENTS on EAP PT approaches 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, 22 Jul 2011 15:27:16 -0000 Juniper supports several forms of EAP method chaining. We support EAP-TTLS and PEAP with a variety of inner authentication methods (EAP-MS-CHAP-V2, EAP-TLS, etc.) and several posture methods also. For SOH compatibility, we support running several EAP methods within PEAP: the SoH EAP Extensions Method followed by MS-CHAP-V2 and then the SoH EAP Extensions Method again. I expect that anyone else who supports SOH over EAP must also support EAP method chaining. That means that Windows XP SP 3, Windows Vista, Windows 7, and Windows Server 2008 would all include this code. Likewise the third-party SOH agents from Avenda and UNETSystem, which run on Mac OS X, Linux, and various old versions of Windows back to Windows 2000. Of course, vendors don't generally provide a fully flexible system for configuring arbitrary sequences of inner methods. But EAP method chaining is often in there, under the hood. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Andreas Steffen > Sent: Friday, July 22, 2011 12:51 AM > To: Joe Salowey > Cc: nea@ietf.org > Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches >=20 > Hello Joe, >=20 > strongSwan either uses certificate-based EAP-TLS client authentication > while setting up the outer EAP-TTLS tunnel that protects the > PT-EAP channel: >=20 > http://www.strongswan.org/uml/testresults45rc/tnc/tnccs-20- > tls/carol.daemon.log >=20 > or uses the chain of EAP-Identity, followed by EAP-MD5/MSCHAPv2/GTC, > followed by PT-EAP within the outer EAP-TTLS tunnel: >=20 > http://www.strongswan.org/uml/testresults45rc/tnc/tnccs- > 20/carol.daemon.log >=20 > Regards >=20 > Andreas >=20 > On 07/22/2011 05:57 AM, Joe Salowey wrote: > > I'm still concerned that many implementations may not support EAP > > chaining. I've been searching online trying to find out how current > > PT-EAP implementations support client authentication. I haven't had > > much luck. Can someone point me to some documentation that explains > > what sort of client authentication the current implementations > > support? > > > > Thanks, > > > > Joe On Jul 12, 2011, at 11:24 AM, Lisa Lorenzin wrote: > > > >> Greetings! > >> > >> Based on the meeting minutes and previous discussion thread, it > >> looks to me like a) there are pros and cons to each approach, and > >> b) either approach would accomplish the technical goals. > >> > >> In the absence of a clear technical front-runner, layer 8 > >> considerations take on greater significance. Since PT-EAP has many > >> more technical implementations, and is based on an open standard > >> from TCG, it seems to better conform to the IETF's emphasis on > >> running code, and to better comply with the RFC 5209 requirement to > >> "prefer the reuse of existing open standards that meet the > >> requirements before defining new ones." > >> > >> Based on those considerations, PT-EAP seems like a better choice. > >> > >> Regards, > >> > >> Lisa > >> > >>> -----Original Message----- From: nea-bounces@ietf.org > >>> [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson > >>> (sethomso) Sent: Thursday, June 30, 2011 18:31 To: nea@ietf.org > >>> Subject: [Nea] CALL for COMMENTS on EAP PT approaches > >>> > >>> One of the outstanding items in the NEA WG is to come to > >>> consensus on whether to use EAP method or TLV for carrying NEA > >>> data in an EAP-based transport. > >>> > >>> Steve Hanna has initiated a thread on this topic on the mailing > >>> list to which some have responded (see pointer below to email > >>> thread and to meeting minutes for summary of discussion at IETF > >>> 80). > >>> > >>> We need more input from the WG to make a decision. Please review > >>> the pros and cons laid out in the thread and provide your input. > >>> Feedback may include any considerations that you think might be > >>> missing from the discussion, as well how you would weigh the > >>> characteristics of the two approaches. > >>> > >>> The deadline for making a decision is by the July IETF. If we do > >>> not, our AD has "offered" to make the decision for us! So please > >>> take the time to post your views. I think it would reflect poorly > >>> on the WG if we are unable to come to consensus ourselves. > >>> > >>> Thanks Susan > >>> > >>> Email Thread starts here: > >>> http://www.ietf.org/mail-archive/web/nea/current/msg01120.html > >>> > >>> Meeting minutes from IETF 80: > >>> http://tools.ietf.org/wg/nea/minutes?item=3Dminutes80.html >=20 > =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=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 > 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) > =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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[ITA-HSR]=3D=3D > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From stefan.winter@restena.lu Fri Jul 22 12:19:31 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 0907C21F8A97 for ; Fri, 22 Jul 2011 12:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] 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 HXAfwTOBZhFM for ; Fri, 22 Jul 2011 12:19:29 -0700 (PDT) Received: from legolas.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id 4416B21F89BA for ; Fri, 22 Jul 2011 12:19:29 -0700 (PDT) Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 1F1C09DD28; Fri, 22 Jul 2011 21:19:25 +0200 (CEST) Received: from [IPv6:2001:4b88:108d::131] (unknown [IPv6:2001:4b88:108d::131]) by legolas.restena.lu (Postfix) with ESMTPSA id A8F509DD14; Fri, 22 Jul 2011 21:19:20 +0200 (CEST) Message-ID: <4E29CD33.9030609@restena.lu> Date: Fri, 22 Jul 2011 21:19:15 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Stephen Hanna References: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> <4E282057.5060602@restena.lu> <4E2973AF.8000208@restena.lu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV Cc: "nea@ietf.org" Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches 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, 22 Jul 2011 19:19:31 -0000 Steve, > I don't know of any standard way to provide information about identity > from the authentication server to the NEA server. Thanks for the clarification. > I suppose that a standard RADIUS attribute could be defined to carry > this information, something like the IF-FTNC-User-Name-Identifier > attribute defined in the Federated TNC specification published at > http://www.trustedcomputinggroup.org/resources/federated_tnc_version_10_revision_26 > However, that attribute was not defined for this exact use case and > I wouldn't propose that anything be done about this now. We have to > finish our work on the basic NEA specifications and this problem is > not part of our agreed-upon use cases for NEA. That reminds me a bit of the EAP-TLVs statements regarding "you could still forward the NEA data somehow, it's just not in the spec" :-) It is really a pity that the use cases do not consider that a NEA server's assessment decisions could be dependent on the identity of the user. I think it is vital that it is *possible* to base such decisions on the connecting identity. And I think we all agree that a auth/NEA server combination that is not co-located is a plausible deployment (after all, in previous meetings and on the mailing list, it was seen as a big advantage of PT-EAP that it can be forwarded independently of the authentication payload). Thinking about it, I think there is a possiblity to read something into the NEA Requirements to that effect, if we want to split a hair or two: C-2 NEA protocols SHOULD provide a way for both the NEA Client and the NEA Server to initiate a posture assessment or reassessment as needed. "As needed" is (probably intentionally) an unspecific term. Assuming that a company policy says "Computers used by Marketing people need to be assessed twice as often as engineering's", the "as needed" includes a requirement that the NEA server knows which identities are behind a certain computing device, so that it can set its re-assessment timers appropriately. Of course, saying that the NEA and auth server need to co-located in such a situation is an answer (but I don't think it has been articulated in the specs so far) - and it's not a very satisfying one, to be honest. Saying that the transport of the user <-> NEA status bindings is out of scope is also an answer, but as I initially stated, this is a result that is on the same level as EAP-TLVs "wrapping NEA data to send off of the authentication server is out of scope" - I find none of the two terribly satisfying. > I'd say that if you have placed your authentication server and your > NEA server on separate machines, you have effectively separated > the functions of authentication and posture checking. Still, the > authentication server could have a policy that says that because > of the user's identity or role, a failed posture check should not > block network access for that user. That's not unusual. > > But I don't think there's any standard way when the authentication > server and the NEA server are separated in this manner to convey > user identity to the NEA server, at least not at this point. If you > want to perform different health checks depending on identity, you > should use a NEA server that's integrated with the authentication > server. That is a bit the crux: the need to co-locate these two servers for a specific use case can be seen as a specific shortcoming of PT-EAP; it is certainly not unavoidable in principle. The EAP-TLV proposal for example brings tieing of the auth+NEA data "built-in". This one goes too far, though: - in EAP-TLV, auth+NEA data always comes bundled, and CANNOT be treated separately - in PT-EAP, auth+NEA data always comes separately, and MUST be treated separately (the requirements document does not require or even mention co-location of NEA and auth server, so I won't consider the argument "they could be co-located" here; we have to consider the general scenario[*]) That is a somewhat sad situation. The "ideal-world" protocol would *permit, but not mandate* to tie auth data and NEA data together, so that every possible deployment can deploy according to its needs. So, I think both proposals are not where they could be. If there was a possibility to retrofit the lacking binding (when looking at PT-EAP) or lacking unbundling (in EAP-TLV), I think that would be desirable. So much for late-evening wishful thinking :-) Greetings, Stefan Winter [*] of course, EAP-TLVs requirement to put NEA data into an authentication payload is in itself awkward when looking at the requirements document - since authentication servers aren't mentioned at all, the requirement to pull-in a user-authentication EAP Type to transport the unrelated NEA data seems misplaced. > > Thanks, > > Steve > >> -----Original Message----- >> From: Stefan Winter [mailto:stefan.winter@restena.lu] >> Sent: Friday, July 22, 2011 8:57 AM >> To: Stephen Hanna >> Cc: nea@ietf.org >> Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches >> >> Hello Steve, all, >> >> thanks for these explanations, they are very helpful. >> >> Could you bear with me one more time, please? It's about the one >> comment >> that your reply didn't touch upon: Assume the authentication server and >> NEA server are separate entities, and that the assessment result of a >> machine varies depending in the user's identity (say, management is >> allowed to drag behind one Windows Service Pack; or that certain >> machine >> types are only tolerated for some user groups). >> >> In that case, the NEA server needs to make different assessments >> dependent on the user identity. Since it is not co-located with the >> authentication server, PT-EAP needs to be forwarded to the NEA server. >> How does the user identity information get to the NEA server, so that >> he >> can make his assessment? Is it possible to blend parts of the >> preceeding >> EAP (authentication) into the contents of the PT-EAP? >> >> In particular, the information that is to be blended in would be the >> inner identity as it was verified by the preceeding EAP method. >> >> Greetings, >> >> Stefan Winter >> >> Am 21.07.2011 16:26, schrieb Stephen Hanna: >>> Stefan, >>> >>> I really appreciate your comments, especially since they are >> practical >>> and based on real-world experience, as are my own. One of the good >> things >>> about NEA is that we've all been solving this problem of endpoint >> assessment >>> for more than five years with a variety of techniques so we can bring >> to >>> bear a great deal of experience in what works and what doesn't, as >> well as >>> what's easy to implement and what's not. >>> >>> I'm not surprised that some people chose to implement SoH support in >>> FreeRADIUS and use that instead of PT-EAP (EAP-TNC). Microsoft >> includes >>> SoH support in Windows XP SP3, Windows Vista, Windows 7, and Windows >>> Server 2008. That's an awfully large installed base! It's hard to >> ignore. >>> Most endpoint assessment vendors have implemented some sort of SoH >>> support, in response to customer demand. That doesn't mean we should >>> assume that SoH does everything right. In fact, the folks at >> Microsoft >>> have supported the NEA effort from the start. They took the lessons >>> learned from SoH (e.g. allow longer messages and multiple round >> trips) >>> and put them into PB-TNC. >>> >>> You mentioned that SoH makes NEA into just another RADIUS attribute. >>> But none of the proposals here involve putting NEA messages into >>> RADIUS attributes. Instead, the NEA messages will be placed into an >>> EAP tunnel method. That's a good thing, since otherwise the NEA >> messages >>> could be flying around with little protection (e.g. no >> confidentiality). >>> In fact, Microsoft uses an EAP tunnel method (PEAP) to carry SoH when >>> it runs over EAP. RADIUS attributes are only used for SoH transport >> when >>> EAP is not available. So I don't think the idea of stuffing NEA >> messages >>> into RADIUS attributes is on the table in this discussion. >>> >>> You raised a concern that PT-EAP requires channel binding. Both L2 >>> PT proposals (PT-EAP and EAP-TLV) use TLS channel bindings only when >>> an External Measurement Agent like TPM is used for hardware-based >>> health checks. So there's no difference in the proposals for that. >>> And TLS channel bindings are only used when hardware-based health >>> checks are used. Anyone who's using hardware-based health checks is >>> already in the top .01% of the class in terms of sophistication, >>> at least today. So I wouldn't worry too much that they're going to >>> need to use TLS channel bindings. They're already on the cutting >>> edge of security technology. Anyway, it's the same for both >> proposals. >>> You make a good point about EAP method chaining. That is fairly new. >>> But I'm not convinced that handling extra TLVs passed in an EAP >>> tunnel method is any less novel. In fact, there has been a lot more >>> work done on analyzing the security properties of EAP method chaining >>> and improving that security than has been done with passing extra >> TLVs. >>> I'm not aware of any papers that analyze the security of passing >> extra >>> TLVs in an EAP tunnel method. There might be real security issues >> there. >>> I appreciate your comments on this. I don't want to dismiss them >>> but rather to take them seriously. We all want to create something >>> here that will be secure and easy to implement and deploy. Your >>> real-world experience is invaluable in that process. Thanks for >>> sharing it. I hope you understand that my comments above are all >>> intended to be constructive and helpful, aiming towards the same >>> goal that you also have. >>> >>> Take care, >>> >>> Steve >>> >>>> -----Original Message----- >>>> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf >> Of >>>> Stefan Winter >>>> Sent: Thursday, July 21, 2011 8:49 AM >>>> To: nea@ietf.org >>>> Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches >>>> >>>> Hello, >>>> >>>>> The deadline for making a decision is by the July IETF. If we do >> not, >>>>> our AD has "offered" to make the decision for us! So please take >> the >>>>> time to post your views. I think it would reflect poorly on the WG >> if >>>> we >>>>> are unable to come to consensus ourselves. >>>> During the meeting, I was one of the few persons who raised a hand >> for >>>> the TLV approach. I would like to shortly explain why. >>>> >>>> First off, of course having existing implementations is good. One >> for >>>> PT-EAP exists in FreeRADIUS, where I came across it. Something >> strange >>>> has happened: even though this implementation was there, people who >>>> tried out NEA decided to leave it aside and write a new extension to >>>> FreeRADIUS that would evaluate MS-SoH. While SoH is not the same as >> the >>>> TLV approach, it is very similar in that it adds attributes to an >>>> existing EAP method. >>>> I also got to try out the SoH support in FreeRADIUS and it came very >>>> natural, because it provides just yet-another-attribute to evaluate. >> I >>>> came to like that approach; and, to be honest, quickly forgot about >> the >>>> TNC library that would do PT-EAP. >>>> >>>> Another argument that is being brought up occasionally is that PT- >> EAP >>>> can be forwarded independently of the user authentication. That's >>>> undoubtedly true (but one has to pay close attention to protect the >>>> forwarding channel, so that NEA data isn't out in clear text!). But >> I >>>> don't really see much use for that - in my view, user authentication >>>> and >>>> the device the user is using are intrinsically linked together. In a >>>> real-life example, yes, one can imagine that a policy "XP SP3 only" >>>> exists, and that the NEA policy is offloaded to a different server >> than >>>> the one which handles the authentication. But it is just as easily >>>> imaginable that the policy *actually* says in fine-print: "But if >> it's >>>> the CEO's device, don't get in his way even with SP1!" and/or "Only >>>> users from the 'Art' department are allowed to bring MACs". That >> makes >>>> for a NEA policy which depends on the user - which would require >>>> sending >>>> user authentication information along with the NEA data, in order to >>>> make a NEA policy decision. I don't think PT-EAP supports >> piggybacking >>>> user-authentication information with NEA data in the PT-EAP datagram >> - >>>> but I may be wrong, of course. I'd appreciate enlightenment :-) >>>> The short conclusion of this overly long paragraph is: I think >>>> authentication and and NEA evaluation belong together in significant >>>> amounts of use cases; so why split them. >>>> >>>> The third point is a small implementation one: PT-EAP needs many >>>> technology prerequisites which are new and not widely deployed in my >>>> experience: channel binding, EAP method chaining. It is a >> significant >>>> implementation hurdle to get all that done right. Adding another >>>> attribute to an existing RADIUS packet, OTOH, is rather simple, dare >> I >>>> say trivial. I could imagine that NEA uptake in implementations will >> be >>>> higher if the number of hoops to jump through is lower. >>>> >>>> I'm well aware that my arguments above are not "hard facts" - I just >>>> have a better feeling regarding the TLV ones. So, I absolutely don't >>>> mind if my concerns get dismissed; but I wanted to raise them >>>> nonetheless. >>>> >>>> Greetings, >>>> >>>> Stefan Winter >>>> >>>> -- >>>> Stefan WINTER >>>> Ingenieur de Recherche >>>> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale >> et >>>> de la Recherche >>>> 6, rue Richard Coudenhove-Kalergi >>>> L-1359 Luxembourg >>>> >>>> Tel: +352 424409 1 >>>> Fax: +352 422473 >>>> >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et >> de la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >> From Paul_Sangster@symantec.com Fri Jul 22 15:53: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 5D79B21F8AFF for ; Fri, 22 Jul 2011 15:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 oIppx9aCHncs for ; Fri, 22 Jul 2011 15:53:24 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) by ietfa.amsl.com (Postfix) with ESMTP id 34D8C21F8ABC for ; Fri, 22 Jul 2011 15:53:24 -0700 (PDT) X-AuditID: d80ac3f1-b7ba2ae000006066-b2-4e29ff63a304 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 58.74.24678.36FF92E4; Fri, 22 Jul 2011 15:53:23 -0700 (MST) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1smtintpin02.ges.symantec.com with esmtp (Exim 4.72) (envelope-from ) id 1QkOax-0006Zw-Mb; Fri, 22 Jul 2011 15:53:23 -0700 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Fri, 22 Jul 2011 15:53:23 -0700 From: Paul Sangster To: Stephen Hanna , Joe Salowey Date: Fri, 22 Jul 2011 15:53:20 -0700 Thread-Topic: [Nea] CALL for COMMENTS on EAP PT approaches Thread-Index: AcxIKxsSMRkaAhAfSiesdK4+83U+kAAVJv4AAA7w4zA= Message-ID: <6E79D623502C70419A9EAB18E4D274252A6A74B93E@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> <189716C74BBB9C4095FE8CA503B1FC3A5525C6A885@EMBX02-HQ.jnpr.net> <4E2901D1.70608@strongswan.org> 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsVyYMX1NN3k/5p+BhN/Glp0HV3LbvH5bYXF 43OnmB2YPab83sjqsWTJTyaP601X2QOYo7hsUlJzMstSi/TtErgy9u1awFaw2rBiypk5LA2M f9S7GDk5JARMJF7/+cwEYYtJXLi3nq2LkYtDSOAjo8Tq5+sYIZzXjBLnXh2FyqxilLh2bDEL SAubgIHEziOn2EFsEQEPiTnNN8DizAKKEtNbl4KNZRFQldjZ2czaxcjBISxgI3Fjow9Eua3E 9LY1YGERASuJbb/FQcK8AlESDYcuskOsWswk8f9UOxtIglPAR2Lz5QfMIDYj0KXfT61hglgl LnHryXyoDwQkluw5zwxhi0q8fPyPFaJeVOJO+3pGiHodiQW7P7FB2NoSyxa+ZoZYLChxcuYT lgmM4rOQjJ2FpGUWkpZZSFoWMLKsYpQpKS02LM4tyS8tKUitMDDUK67MTQRGXbJecn7uJkZg 5N3gOvxxB+P1pYqHGAU4GJV4eGu/aPoJsSaWAVUeYpTgYFYS4fVeCRTiTUmsrEotyo8vKs1J LT7EKM3BoiTOW/oGKCWQnliSmp2aWpBaBJNl4uCUamCstLbc0dgrXb9rb6f3Ga0kn1n68gX2 dWzNVaE/FnjLHrp8e97cZ97bUyOni837eaUv37jo+pM/759bF/us/qO0LjHN2umtxZEKH8/1 Hpz3eMoFhO7sEN5zcPqHKU5fOQrOWN4+ku4S8qps1zXNs9FLL4SfO5j0Kscofd/PRXPUBPb6 B+s0ORxUYinOSDTUYi4qTgQAEdIko7gCAAA= Cc: "nea@ietf.org" Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches 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, 22 Jul 2011 22:53:25 -0000 The OpenSEA (Open1X) open source supplicant also supports several chaining = variations of EAP methods. The most common is PEAP / MSCHAPv2 / EAP-TNC. = Note that the Open1X supplicant has protocol support for PA-TNC and PB-TNC. > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Friday, July 22, 2011 8:26 AM > To: Joe Salowey > Cc: nea@ietf.org > Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches >=20 > Juniper supports several forms of EAP method chaining. We support > EAP-TTLS and PEAP with a variety of inner authentication methods > (EAP-MS-CHAP-V2, EAP-TLS, etc.) and several posture methods also. >=20 > For SOH compatibility, we support running several EAP methods within > PEAP: the SoH EAP Extensions Method followed by MS-CHAP-V2 and then > the SoH EAP Extensions Method again. I expect that anyone else who > supports SOH over EAP must also support EAP method chaining. That > means that Windows XP SP 3, Windows Vista, Windows 7, and Windows > Server 2008 would all include this code. Likewise the third-party > SOH agents from Avenda and UNETSystem, which run on Mac OS X, Linux, > and various old versions of Windows back to Windows 2000. >=20 > Of course, vendors don't generally provide a fully flexible system > for configuring arbitrary sequences of inner methods. But EAP method > chaining is often in there, under the hood. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > > Andreas Steffen > > Sent: Friday, July 22, 2011 12:51 AM > > To: Joe Salowey > > Cc: nea@ietf.org > > Subject: Re: [Nea] CALL for COMMENTS on EAP PT approaches > > > > Hello Joe, > > > > strongSwan either uses certificate-based EAP-TLS client > authentication > > while setting up the outer EAP-TTLS tunnel that protects the > > PT-EAP channel: > > > > http://www.strongswan.org/uml/testresults45rc/tnc/tnccs-20- > > tls/carol.daemon.log > > > > or uses the chain of EAP-Identity, followed by EAP-MD5/MSCHAPv2/GTC, > > followed by PT-EAP within the outer EAP-TTLS tunnel: > > > > http://www.strongswan.org/uml/testresults45rc/tnc/tnccs- > > 20/carol.daemon.log > > > > Regards > > > > Andreas > > > > On 07/22/2011 05:57 AM, Joe Salowey wrote: > > > I'm still concerned that many implementations may not support EAP > > > chaining. I've been searching online trying to find out how > current > > > PT-EAP implementations support client authentication. I haven't > had > > > much luck. Can someone point me to some documentation that > explains > > > what sort of client authentication the current implementations > > > support? > > > > > > Thanks, > > > > > > Joe On Jul 12, 2011, at 11:24 AM, Lisa Lorenzin wrote: > > > > > >> Greetings! > > >> > > >> Based on the meeting minutes and previous discussion thread, it > > >> looks to me like a) there are pros and cons to each approach, and > > >> b) either approach would accomplish the technical goals. > > >> > > >> In the absence of a clear technical front-runner, layer 8 > > >> considerations take on greater significance. Since PT-EAP has > many > > >> more technical implementations, and is based on an open standard > > >> from TCG, it seems to better conform to the IETF's emphasis on > > >> running code, and to better comply with the RFC 5209 requirement > to > > >> "prefer the reuse of existing open standards that meet the > > >> requirements before defining new ones." > > >> > > >> Based on those considerations, PT-EAP seems like a better choice. > > >> > > >> Regards, > > >> > > >> Lisa > > >> > > >>> -----Original Message----- From: nea-bounces@ietf.org > > >>> [mailto:nea-bounces@ietf.org] On Behalf Of Susan Thomson > > >>> (sethomso) Sent: Thursday, June 30, 2011 18:31 To: nea@ietf.org > > >>> Subject: [Nea] CALL for COMMENTS on EAP PT approaches > > >>> > > >>> One of the outstanding items in the NEA WG is to come to > > >>> consensus on whether to use EAP method or TLV for carrying NEA > > >>> data in an EAP-based transport. > > >>> > > >>> Steve Hanna has initiated a thread on this topic on the mailing > > >>> list to which some have responded (see pointer below to email > > >>> thread and to meeting minutes for summary of discussion at IETF > > >>> 80). > > >>> > > >>> We need more input from the WG to make a decision. Please review > > >>> the pros and cons laid out in the thread and provide your input. > > >>> Feedback may include any considerations that you think might be > > >>> missing from the discussion, as well how you would weigh the > > >>> characteristics of the two approaches. > > >>> > > >>> The deadline for making a decision is by the July IETF. If we do > > >>> not, our AD has "offered" to make the decision for us! So please > > >>> take the time to post your views. I think it would reflect poorly > > >>> on the WG if we are unable to come to consensus ourselves. > > >>> > > >>> Thanks Susan > > >>> > > >>> Email Thread starts here: > > >>> http://www.ietf.org/mail-archive/web/nea/current/msg01120.html > > >>> > > >>> Meeting minutes from IETF 80: > > >>> http://tools.ietf.org/wg/nea/minutes?item=3Dminutes80.html > > > > > =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=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 > > 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) > > =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=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D[ITA- > HSR]=3D=3D > > _______________________________________________ > > 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