From internet-drafts@ietf.org Thu Mar 8 13:28:56 2012 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 7582B21F852D; Thu, 8 Mar 2012 13:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24V4F4Dqrz4k; Thu, 8 Mar 2012 13:28:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 001C621F8498; Thu, 8 Mar 2012 13:28:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308212847.15156.1446.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 13:28:47 -0800 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-tls-02.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 21:28:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Endpoint Assessment Working G= roup of the IETF. Title : PT-TLS: A TCP-based Posture Transport (PT) Protocol Author(s) : Paul Sangster Nancy Cam-Winget Joseph Salowey Filename : draft-ietf-nea-pt-tls-02.txt Pages : 52 Date : 2012-03-08 This document specifies PT-TLS, a TCP-based Posture Transport (PT) protocol. The PT-TLS protocol 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-02.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-02.txt From internet-drafts@ietf.org Fri Mar 9 15:30:48 2012 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 9920321E803E; Fri, 9 Mar 2012 15:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eii9g6XN7Jm0; Fri, 9 Mar 2012 15:30:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E1321E8018; Fri, 9 Mar 2012 15:30:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309233048.19242.38008.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 15:30:48 -0800 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-eap-01.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 23:30:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Endpoint Assessment Working G= roup of the IETF. Title : PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel M= ethods Author(s) : Nancy Cam-Winget Paul Sangster Filename : draft-ietf-nea-pt-eap-01.txt Pages : 20 Date : 2012-03-09 This document specifies PT-EAP, an EAP based Posture Transport (PT) protocol designed to be used only inside TLS protected tunnel method. As such, the document also describes the intended applicability of PT-EAP as well as the evaluation against the requirements defined in the NEA Requirements and PB-TNC specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-eap-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-nea-pt-eap-01.txt From shanna@juniper.net Fri Mar 9 15:40:11 2012 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 B4F2921E8046 for ; Fri, 9 Mar 2012 15:40:11 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paObvNo8Qncn for ; Fri, 9 Mar 2012 15:40:10 -0800 (PST) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 78A8A21E8019 for ; Fri, 9 Mar 2012 15:40:10 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT1qU2iTkOjs140EFPGM+duIv/yDI3qw7@postini.com; Fri, 09 Mar 2012 15:40:10 PST Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 9 Mar 2012 15:39:49 -0800 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 9 Mar 2012 15:39:49 -0800 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, 9 Mar 2012 18:39:48 -0500 From: Stephen Hanna To: "nea@ietf.org" Date: Fri, 9 Mar 2012 18:39:46 -0500 Thread-Topic: WGLC on PT-TLS and PT-EAP Thread-Index: Acz+TelgmnZrdQC7Qb6iHBKCQDXPcQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Nea] WGLC on PT-TLS and PT-EAP 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, 09 Mar 2012 23:40:11 -0000 The editors of PT-TLS and PT-EAP have posted new drafts that address all the comments received during the recent reviews and WGLCs. In order to spark review of these new drafts, we'll be running a WGLC on these documents starting today and running for two weeks, ending at 2359 GMT on Friday, March 23. This should give us plenty of comments and maybe some thorny issues to discuss at our meeting at IETF 83 in Paris. So please review these documents and send your comments to the nea@ietf.org email list. The URLs for the new drafts are: http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-02.txt http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-eap-01.txt Thanks for your careful attention, Steve Hanna From sethomso@cisco.com Fri Mar 9 16:02:52 2012 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 58AB121F85F2 for ; Fri, 9 Mar 2012 16:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.099 X-Spam-Level: X-Spam-Status: No, score=-109.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBxjsq0QjoUD for ; Fri, 9 Mar 2012 16:02:51 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 46A9021F8565 for ; Fri, 9 Mar 2012 16:02:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=969; q=dns/txt; s=iport; t=1331337771; x=1332547371; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=BBX713EDp1ZXB380pVQX0CDut5WUVfTGXoGFF8BKi0w=; b=ODzoe7cqbK/wgtL628PYeWbpJTPep+Jzk/TP5exaazo+iS+pcWshZj9z HVIvCjuvf76USRFf9CoRE06O5X1TSIsHa4gbVy45EmUqtb2Y3xtO1LAce dNgFqhScPUM/GF4retlMiV1wmx9i2qHVJ14ZEc6cSiCpnONdbIft/Xzjb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHGZWk+tJXG+/2dsb2JhbABDtTWBB4IMAQQSAScCAU4BHIEKAQQTCRmHaAuaWYEnAZ5wjVaDIgSIU4x2kByDAYE+ X-IronPort-AV: E=Sophos;i="4.73,561,1325462400"; d="scan'208";a="62236989" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 10 Mar 2012 00:02:51 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2A02o8L001049 for ; Sat, 10 Mar 2012 00:02:50 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 18:02:50 -0600 Received: from 10.116.64.103 ([10.116.64.103]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Sat, 10 Mar 2012 00:02:50 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 09 Mar 2012 19:02:45 -0500 From: Susan Thomson To: Message-ID: Thread-Topic: Draft NEA WG agenda for IETF 83 Thread-Index: Acz+UR7V7pLhkev0fUKIhanBWE+/Fw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Mar 2012 00:02:50.0966 (UTC) FILETIME=[22639760:01CCFE51] Subject: [Nea] Draft NEA WG agenda for IETF 83 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 00:02:52 -0000 Hi all Draft agenda below. Please let me know if you have comments/additions by Fri 03/16/2012. Thanks Susan Note: The Asokan -00 I-D has expired and will be updated Monday. ------------------------------ Agenda for IETF 83 NEA WG meeting ================================= Date: Wednesday, Mar 28 2011 Time: 1300-1500 CET (GMT+1) WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 1300 Administrivia Blue Sheets Jabber & Minute scribes Agenda bashing 1305 WG Status 1310 NEA Reference Model 1315 Discuss and Resolve WGLC PT-TLS Comments http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-02.txt 1350 Discuss and Resolve WGLC PT-EAP Issues http://www.ietf.org/id/draft-ietf-nea-pt-eap-01.txt 1425 Discuss next steps for NEA Asokan I-D http://tools.ietf.org/id/draft-salowey-nea-asokan-01.txt 1450 Next Steps 1500 Adjourn From jsalowey@cisco.com Fri Mar 9 16:43:22 2012 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 578D221F86DB for ; Fri, 9 Mar 2012 16:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.599 X-Spam-Level: X-Spam-Status: No, score=-109.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yySSJKTC3e9o for ; Fri, 9 Mar 2012 16:43:21 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id C80F821F86D8 for ; Fri, 9 Mar 2012 16:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=402; q=dns/txt; s=iport; t=1331340201; x=1332549801; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=o53aw6E7Nb1XLMIFO3naaES3te8BfW5zvZEk7snS+5w=; b=CwnHcVJDPscA7ohL7/F+yyYU1bMRan5oKW4+XnAoNMOp0hH7D73c0jNH fZlN88u27KAooNmJmHfmIyhg7ddpSgw0xSZ0yEGpB9T1jlkyxAK1qvn4a 1yd8siUWoLoeJyvDYiPxXccrRC7xvbmaj1k6XEvrH7BDAQNbhkLeJURcn I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQFAH2jWk+rRDoH/2dsb2JhbABDgwmyLIEHgiMBJ4Iyh2eaYoEnAZ5sjVaCP2MEiFOMdoVmijaDBA X-IronPort-AV: E=Sophos;i="4.73,561,1325462400"; d="scan'208";a="35457796" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 10 Mar 2012 00:43:14 +0000 Received: from [10.33.251.187] ([10.33.251.187]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2A0hDCo032593 for ; Sat, 10 Mar 2012 00:43:13 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 16:43:04 -0800 Message-Id: To: nea@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Nea] Asokan attack draft X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 00:43:22 -0000 We had some previous discussion on expanding the scope of the Asokan = draft to beyond the NEA scenario. The looks to involve a fair amount of = work to cover the general case. I'm thinking that focusing on and how = the Asokan attack applies to NEA and how it is mitigated in NEA would be = much better bounded and some thing we could complete more quickly. =20 Comments? Thanks, Joe= From shanna@juniper.net Fri Mar 9 18:26:35 2012 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 95DF021E8018 for ; Fri, 9 Mar 2012 18:26:35 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n26KQP3TxMHh for ; Fri, 9 Mar 2012 18:26:35 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0B50B11E8072 for ; Fri, 9 Mar 2012 18:26:33 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKT1q72emZqgnIPjFshqxzMFSaoOKnKH58@postini.com; Fri, 09 Mar 2012 18:26:34 PST 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.3.213.0; Fri, 9 Mar 2012 18:26:13 -0800 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, 9 Mar 2012 21:26:12 -0500 From: Stephen Hanna To: Joe Salowey , "nea@ietf.org" Date: Fri, 9 Mar 2012 21:26:10 -0500 Thread-Topic: [Nea] Asokan attack draft Thread-Index: Acz+Vs2pVpAy4X6TSbGUvQaezEghqAADVxog Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Nea] Asokan attack draft X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 02:26:35 -0000 Yes, Joe. I agree. The Asokan attack does have broader implications beyond NEA but explaining and analyzing those properly would require the active involvement of at least the EMU WG. They're quite busy so doing this would slow down the completion of the NEA WG's efforts. Anyway, the original Asokan paper does a good job of explaining the implications for tunnel EAP methods. However, it doesn't explain the implications for endpoint assessment. That's the special value of this draft. I'll update the NEA Asokan draft so that it's up-to-date (adding references to PT-EAP and PT-TNC, etc.) and submit that updated version before Monday's non-00 deadline. The NEA WG can discuss this more and decide whether we want to take that on as WG draft headed for Informational status or to have us submit it as an AD-sponsored submission or whatever. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Joe Salowey > Sent: Friday, March 09, 2012 7:43 PM > To: nea@ietf.org > Subject: [Nea] Asokan attack draft >=20 > We had some previous discussion on expanding the scope of the Asokan > draft to beyond the NEA scenario. The looks to involve a fair amount > of work to cover the general case. I'm thinking that focusing on and > how the Asokan attack applies to NEA and how it is mitigated in NEA > would be much better bounded and some thing we could complete more > quickly. >=20 > Comments? >=20 > Thanks, >=20 > Joe > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From ncamwing@cisco.com Fri Mar 9 19:13:14 2012 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 E8D7321E8039 for ; Fri, 9 Mar 2012 19:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0qj61AQsst1 for ; Fri, 9 Mar 2012 19:13:09 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4696621E8021 for ; Fri, 9 Mar 2012 19:13:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ncamwing@cisco.com; l=21276; q=dns/txt; s=iport; t=1331349189; x=1332558789; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=315UShRLw2QJe349D2blVsUazeaUk6DiIOaujQE/oBE=; b=HXZcQenLzjiB5aW2B5DXsnlGSYbyHWMrPu2qBh/Q+4GteDnQgbV/iplO VtEDfGN1o15gm0Rfvx7c/FEC4/SX93llZhENKd4pe+SdDEhPCYGPZBqLw yGcwtXb1QTkgmwIUnxqkGcO84wgGQ0d4wfq8mxn/x6+3SbS/6PHHmn4gw s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKLFWk+rRDoI/2dsb2JhbABCglKxf3SBB4IKAQEBAwESASo8BQ0BCIEdAQEEAQ0FIodjBAGgIwGXAZB4BIggM4x2kByDBIE1Fw X-IronPort-AV: E=Sophos;i="4.73,561,1325462400"; d="scan'208,217";a="32658586" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 10 Mar 2012 03:13:08 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2A3D8St003478; Sat, 10 Mar 2012 03:13:08 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 19:13:08 -0800 Received: from 10.21.147.164 ([10.21.147.164]) by xmb-sjc-221.amer.cisco.com ([128.107.191.80]) with Microsoft Exchange Server HTTP-DAV ; Sat, 10 Mar 2012 03:13:08 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 09 Mar 2012 19:13:06 -0800 From: Nancy Cam-Winget To: , Message-ID: Thread-Topic: review of draft-ietf-nea-pt-eap-00.txt Thread-Index: AcziDrAE1hU3CovTTaa6IG1T1kr34gcXQZAb In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3414165186_73968659" X-OriginalArrivalTime: 10 Mar 2012 03:13:08.0515 (UTC) FILETIME=[B7C74F30:01CCFE6B] Subject: Re: [Nea] review of draft-ietf-nea-pt-eap-00.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 03:13:15 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3414165186_73968659 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Kathleen, Many thanks for the careful review, I have tried to incorporate most of you= r comments and suggestions in the recently updated draft but had some further questions/comments belo= w (we can also discuss them at the IETF if you will be there?): On 2/2/12 4:56 PM, "kathleen.moriarty@emc.com" wrote: =20 > Hello Nancy and Paul, >=20 > I volunteered to review the draft for the working group. The document lo= oks > very good. A number of my comments are nits and some are areas in which = the > document can benefit from additional specificity. Here are my comments: >=20 > Section 3.1, could you include a diagram? I think that will help the rea= der > to see the flow on first read. The text reads well, but not being famili= ar > with the draft, I had to read it twice to make sure I had the background = to > continue reading. It would be useful to reference while reading section = 3.2 > as well. > [NCW] Will be happy to include a diagram but I wasn=B9t exactly sure as to > whether you were looking for an > PT-EAP vs. EAP-tunnel-method+PT-EAP flow or general encapsulation of PT-E= AP > inside a tunnel method. > If you can provide more guidance, I can make an attempt at such a diagram= . >=20 > Section 3.3: Just a suggestion to reword the first paragraph: > In most cases, EAP-TNC fragmentation will not be required. However, PB-TN= C > batches can be very long and EAP message length is sometimes tightly > constrained. As a result, EAP-TNC includes a fragmentation mechanism = to be > used > when a particular PB-TNC batch is too long to fit into a single EAP- > TNC message. > [NCW] Given that there was agreement that PT-EAP did not need fragmentati= on I > think that this > and the next few comments no longer need to be addressed. >=20 > Section 3.3: It would be helpful to distinguish the differences from the > referenced specifications so that a developer knows where this specificat= ion > differs. >=20 > "The fragmentation mechanism used in EAP-TNC is quite similar to the > mechanism used by EAP-TLS [17], EAP-TTLS [14], and EAP-FAST [12]. It > uses the L flag (length included) and the M flag (more fragments) as > well as the Data Length field." >=20 > In the following paragraphs, including the references to the appropriate = spec > where there is a match and then pointing out the difference could be usef= ul. >=20 > Section 3.3: Is there a reference that can be included to where one can f= ind > the 'variety of reasons' in the last paragraph? > "However, a > NEA Server or peer still MAY decide to terminate an EAP-TNC exchange > at any time for a variety of reasons." >=20 > Section 3.4: Type, I had the word please in a draft :) and someone recomm= ended > pulling it out and just directly making the request. You may want to do = the > same here. > [NCW] The note has been removed as the Type must now be assigned by IANA. >=20 > Section 3.4 Data Length: Recommend adding a comma in the first sentence a= nd > removing two in the second: > Data Length is an optional field, four octets in length. When present, it > indicates the total length before fragmentation of a fragmented > PB-TNC batch. > [NCW] The sentence/paragraph was reworked given that there is no fragment= ation > within PT-EAP. >=20 > Section 3.5: Should 'SHOULD' be 'MUST' in the following sentence to prot= ect > against the attack? If this is not required of the protocol, then I sugg= est > using non RFC2119 language, something like the following: > To protect against NEA Asokan attacks, it is necessary for the Posture Br= oker > on an EMA- > equipped endpoint to pass the tls-unique channel binding [18] for > PT-EAP's tunnel method to the EMA. > [NCW] Updated per your suggestion. >=20 > I think the following sentence should be broken into two as follows (left= in > the page information so you can find it): > This value can then be included >=20 >=20 > Sangster et al. Expires February 30, 2012 [Page 10] >=20 > Internet-Draft PT-EAP August 2011 >=20 >=20 > in the EMA's attestation and the Posture Validator responsible for > communicating with the EMA. The EMA may then confirm that the value > matches > the tls-unique channel binding for its end of the tunnel. > [NCW] I=B9ve updated the text to reflect that it is the Posture Validator w= ho is > validating the tls-unique passed by the NEA Client to the EMA. Please le= t me > know if it is still unclear and we can try to make further adjustments. >=20 >=20 > Can you reword the following sentence (next one in this section)? It is = a > little tough for me to follow: > "If the > values match and the integrity of the endpoint is good, the posture > sent by the EMA and NEA Client is from the same endpoint as the > client side of the TLS connection (since the endpoint knows the tls- > unique value) so no man-in-the-middle is forwarding posture." > [NCW] Reworded to =B3If the tls-unique values between the NEA Client and NE= A > Server match endpoint, then the posture sent by the EMA (and thus the NEA > Client) is from the same endpoint as the client side of the TLS connectio= n > (since the endpoint knows the tls-unique value) so no man-in-the-middle i= s > forwarding posture.=B2 > Again, please let me know if further adjustments need to be made. >=20 >=20 > Security Considerations: Could you reference the documents where the secu= rity > requirements exist. I like that the introduction to this section clearly > states that these are recommendations and not the requirements, but want = o be > sure the requirements are directly referenced. > [NCW] RFC5209 has been added as the reference. >=20 > In section 4.2.1, RFC2119 terms are used, this means they are requirement= s. > Is that the case? If so, you may want to have a Security Requirements se= ction > prior to your Security Considerations Section and include items like thes= e. > It is starting to become a trend in drafts so that security requirements = are > not ignored by developers. This particular statement is high-level, so y= ou > may want to change it to use language not defined in RFC2119, but clearly > point to the specification that provides the details of how the authentic= ation > and other security features are provided in the introduction. > [NCW] In the interest of time and discussion, I=B9d like to leave this one = for > us to close at the IETF meeting. > I think I=B9m OK moving the EAP Tunnel Security requirements but then am no= t > sure that would leave much in the Security Considerations....or, we could= also > soften the language. But I would like to get others in the WG to > chime in as well.... >=20 > Section 4.2.2, Consider breaking the last sentence into multiple sentence= s. > [NCW] The last sentence of the last paragraph has been split into > two....please let me know if more is needed. >=20 > Section 4.2.5 also contains an RFC2119 term. This is fine, just point it= out > as you decide how to handle considerations versus requirements with the > current introductory remarks. > [NCW] Again, I=B9ve put this in the general topic of =B3how to organized the > requirements vs. considerations=B2 > for us to discuss at the IETF (and of course, can continue to do so in th= e > reflector as well). >=20 > Same for 4.3: This includes a set of requirements nested inside a section= that > says it is not requirements. >=20 > Section 4.3: I think you need to be more specific and provide references = to > the acceptable authentication options to have interoperability between > implementations. >=20 > Section 4.4: I like seeing the reference to TLS, can you also include the > references to EAP-FAST and EAP-TLS here so the reader has links to the RF= Cs > when the document is published? It could help them figure out things lik= e the > necessary version of TLS to support, etc. I realize this is already > referenced higher in the document, so it is just to be helpful to the > reader/developer. > [NCW] References have been added. >=20 > Section 4.4: Last paragraph, this goes into authentication, but doesn't > provide a reference to the appropriate specs to follow either. > [NCW] Added EAP-FAST and TTLS as examples (with references). >=20 > Section 4.5: It may only be me, but I had to read the introductory sente= nce a > couple of times to get the context - to make sure I had it right. Can yo= u add > 'for this specification' or something like that to the sentence? > [NCW] Updated per your suggestion. >=20 > Section 6: I think you can make a direct statement requesting registratio= n of > the value. This text will live on in the document after the value is > assigned. Maybe ask IANA, but in the draft make it more direct - Registe= rs > value 38... > [NCW] Text has been updated to reflect that IANA must assign a new EAP va= lue. >=20 > Section 6.1 looks good - I just finished similar IANA requests. > [NCW] Thanks! >=20 >=20 > I am just in the NEA-digest list, so if you would like me to see it right > away, you may want to copy me directly. >=20 > Thank you, > Kathleen >=20 >=20 >=20 >=20 --B_3414165186_73968659 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: review of draft-ietf-nea-pt-eap-00.txt Hi Kathleen,

Many thanks for the careful review, I have tried to incorporate most of you= r comments and suggestions
 in the recently updated draft but had some further questions/comments= below (we can also discuss
 them at the IETF if you will be there?):


On 2/2/12 4:56 PM, "kathleen.moria= rty@emc.com" <kathleen.moria= rty@emc.com> wrote:
 
Hello Nancy and Paul,

I volunteered to review the draft for the working group.  The document= looks very good.  A number of my comments are nits and some are areas = in which the document can benefit from additional specificity.  Here ar= e my comments:

Section 3.1, could you include a diagram?  I think that will help the = reader to see the flow on first read.  The text reads well, but not bei= ng familiar with the draft, I had to read it twice to make sure I had the ba= ckground to continue reading.  It would be useful to reference while re= ading section 3.2 as well.
[NCW] Will be happy to include a diagram but I wasn&#= 8217;t exactly sure as to whether you were looking for an
PT-EAP vs. EAP-tunnel-method+PT-EAP flow or general encapsulation of PT-EAP= inside a tunnel method.
If you can provide more guidance, I can make an attempt at such a diagram.<= BR>
Section 3.3: Just a suggestion to reword the first paragraph:
In most cases, EAP-TNC fragmentation will not be required. However, PB-TNC<= BR>    batches can be very long and EAP message length is someti= mes tightly
   constrained.  As a result, EAP-TNC includes a fragme= ntation mechanism to be used
   when a particular PB-TNC batch is too long to fit into a = single EAP-
   TNC message.
[NCW] Given that there was agreement that PT-EAP did = not need fragmentation I think that this
and the next few comments no longer need to be addressed.

Section 3.3: It would be helpful to distinguish the differences from the re= ferenced specifications so that a developer knows where this specification d= iffers.

"The fragmentation mechanism used in EAP-TNC is quite similar to the    mechanism used by EAP-TLS [17], EAP-TTLS [14], and EAP-FA= ST [12]. It
   uses the L flag (length included) and the M flag (more fr= agments) as
   well as the Data Length field."

In the following paragraphs, including the references to the appropriate sp= ec where there is a match and then pointing out the difference could be usef= ul.

Section 3.3: Is there a reference that can be included to where one can fin= d the 'variety of reasons' in the last paragraph?
"However, a
   NEA Server or peer still MAY decide to terminate an EAP-T= NC exchange
   at any time for a variety of reasons."

Section 3.4: Type, I had the word please in a draft :) and someone recommen= ded pulling it out and just directly making the request.  You may want = to do the same here.
[NCW] The note has been removed as the Type must now = be assigned by IANA.

Section 3.4 Data Length: Recommend adding a comma in the first sentence and= removing two in the second:
Data Length is an optional field, four octets in length. When present, it       indicates the total length before fragm= entation of a fragmented
      PB-TNC batch.
[NCW] The sentence/paragraph was reworked given that = there is no fragmentation within PT-EAP.

Section 3.5:  Should 'SHOULD' be 'MUST' in the following sentence to p= rotect against the attack?  If this is not required of the protocol, th= en I suggest using non RFC2119 language, something like the following:
To protect against NEA Asokan attacks, it is necessary for the Posture Brok= er on an EMA-
   equipped endpoint to pass the tls-unique channel binding = [18] for
   PT-EAP's tunnel method to the EMA.
[NCW] Updated per your suggestion.

I think the following sentence should be broken into two as follows (left i= n the page information so you can find it):
This value can then be included


Sangster et al.       Expires February 30, 20= 12             &= nbsp; [Page 10]

Internet-Draft           =        PT-EAP     &nb= sp;            &= nbsp;   August 2011


   in the EMA's attestation and the Posture Validator respon= sible for
   communicating with the EMA.  The EMA may then confir= m that the value matches
   the tls-unique channel binding for its end of the tunnel.=
[NCW] I’ve updated the text to reflect that it = is the Posture Validator who is validating the tls-unique passed by the NEA = Client to the EMA.  Please let me know if it is still unclear and we ca= n try to make further adjustments.


Can you reword the following sentence (next one in this section)?  It = is a little tough for me to follow:
"If the
   values match and the integrity of the endpoint is good, t= he posture
   sent by the EMA and NEA Client is from the same endpoint = as the
   client side of the TLS connection (since the endpoint kno= ws the tls-
   unique value) so no man-in-the-middle is forwarding postu= re."
[NCW] Reworded to “If the tls-unique values = between the NEA Client and NEA Server match endpoint, then the posture sent = by the EMA (and thus the NEA Client) is from the same endpoint as the client= side of the TLS connection  (since the endpoint knows the tls-unique v= alue) so no man-in-the-middle is forwarding posture.”
Again, please let me know if further adjustments need to be made.


Security Considerations: Could you reference the documents where the securi= ty requirements exist.  I like that the introduction to this section cl= early states that these are recommendations and not the requirements, but wa= nt o be sure the requirements are directly referenced.
[NCW] RFC5209 has been added as the reference.

In section 4.2.1, RFC2119 terms are used, this means they are requirements.=  Is that the case?  If so, you may want to have a Security Requir= ements section prior to your Security Considerations Section and include ite= ms like these.  It is starting to become a trend in drafts so that secu= rity requirements are not ignored by developers.  This particular state= ment is high-level, so you may want to change it to use language not defined= in RFC2119, but clearly point to the specification that provides the detail= s of how the authentication and other security features are provided in the = introduction.
[NCW] In the interest of time and discussion, I’= ;d like to leave this one for us to close at the IETF meeting.
I think I’m OK moving the EAP Tunnel Security requirements but then a= m not sure that would leave much in the Security Considerations....or, we co= uld also soften the language.  But I would like to get others in the WG= to
chime in as well....

Section 4.2.2, Consider breaking the last sentence into multiple sentences.=
[NCW] The last sentence of the last paragraph has bee= n split into two....please let me know if more is needed.

Section 4.2.5 also contains an RFC2119 term.  This is fine, just point= it out as you decide how to handle considerations versus requirements with = the current introductory remarks.
[NCW] Again, I’ve put this in the general topic= of “how to organized the requirements vs. considerations”
for us to discuss at the IETF (and of course, can continue to do so in the = reflector as well).

Same for 4.3: This includes a set of requirements nested inside a section t= hat says it is not requirements.

Section 4.3: I think you need to be more specific and provide references to= the acceptable authentication options to have interoperability between impl= ementations.

Section 4.4: I like seeing the reference to TLS, can you also include the r= eferences to EAP-FAST and EAP-TLS here so the reader has links to the RFCs w= hen the document is published?  It could help them figure out things li= ke the necessary version of TLS to support, etc.  I realize this is alr= eady referenced higher in the document, so it is just to be helpful to the r= eader/developer.
[NCW] References have been added.

Section 4.4: Last paragraph, this goes into authentication, but doesn't pro= vide a reference to the appropriate specs to follow either.
[NCW] Added EAP-FAST and TTLS as examples (with refer= ences).

Section 4.5:  It may only be me, but I had to read the introductory se= ntence a couple of times to get the context - to make sure I had it right. &= nbsp;Can you add 'for this specification' or something like that to the sent= ence?
[NCW] Updated per your suggestion.

Section 6: I think you can make a direct statement requesting registration = of the value.  This text will live on in the document after the value i= s assigned.  Maybe ask IANA, but in the draft make it more direct - Reg= isters value 38...
[NCW] Text has been updated to reflect that IANA must= assign a new EAP value.

Section 6.1 looks good - I just finished similar IANA requests.
[NCW] Thanks!


I am just in the NEA-digest list, so if you would like me to see it right a= way, you may want to copy me directly.

Thank you,
Kathleen




--B_3414165186_73968659-- From ncamwing@cisco.com Fri Mar 9 19:29:40 2012 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 B66E021E8042 for ; Fri, 9 Mar 2012 19:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.202 X-Spam-Level: X-Spam-Status: No, score=-9.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cti3yqv7R9mq for ; Fri, 9 Mar 2012 19:29:39 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 11C8921E8018 for ; Fri, 9 Mar 2012 19:29:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ncamwing@cisco.com; l=3772; q=dns/txt; s=iport; t=1331350179; x=1332559779; h=date:subject:from:to:message-id:mime-version; bh=I046JewpokNoPVMGAlSTD/DDgW+w7oFvyuRtbcXi85M=; b=NNLUZqrfnTt3KKd4lWZpSRLhNkSbcNHQgnsEC8bLzbDLndiyFlaX0kHq uuVdbdpX1vk0z5uz5AeNwsdLdZLubA7QxZK//XQx4Kd6s5Hm+Lt06+xHf EJ1WqvJEyuLJQ6BKSkn+I6AvaDck0NWePOaXpLs01P8qF8JRFTS8fUmpY 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALnJWk+rRDoG/2dsb2JhbABDgkWxf3SBB4IMAQQSAQoKFk4BCASBGgEENYdnAZpegScBnmWNVoMiBIggM4x2kByDBA X-IronPort-AV: E=Sophos;i="4.73,561,1325462400"; d="scan'208,217";a="32878228" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 10 Mar 2012 03:29:39 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2A3Tcqh000561 for ; Sat, 10 Mar 2012 03:29:38 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 19:29:38 -0800 Received: from 10.21.147.164 ([10.21.147.164]) by xmb-sjc-221.amer.cisco.com ([128.107.191.80]) with Microsoft Exchange Server HTTP-DAV ; Sat, 10 Mar 2012 03:29:38 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 09 Mar 2012 19:29:37 -0800 From: Nancy Cam-Winget To: Message-ID: Thread-Topic: [Nea] NEA WG Next Steps: Call for Comments on PT-EAP I-D Thread-Index: Acz+bgT2zw9xDzAfWkagzJzyclsNpg== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3414166178_74033928" X-OriginalArrivalTime: 10 Mar 2012 03:29:38.0874 (UTC) FILETIME=[061419A0:01CCFE6E] Subject: Re: [Nea] NEA WG Next Steps: Call for Comments on PT-EAP 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: Sat, 10 Mar 2012 03:29:40 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3414166178_74033928 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Carolin, For some reason I can not respond to your review directly so am sending to the NEA Reflector...Thanks for taking the time to review the PT-EAP draft and provide comments. I=B9ve incorporated all your suggested updates in the latest draft-ietf-nea-pt-eap-01 Draft. To your question: Section 3.2 - "The NEA Client SHOULD choose the value sent by the NEA Server if the NEA Client supports it. However, the NEA Client MAY set the Version field to a value less than the value sent by the NEA Server" -> does this mean, the client is allowed to choose an older version even he supports the same version like the server. Wouldn't it be better to require the client to use the version the server requested if he supports it and only allow to use older versions if the client does not support the server'= s version? [NCW] Yes, the intent is to have the client negotiate the newest version it has, but it is difficult to discern this and thus the server can only presume the client is negotiating a lower version because it can not support a newer (higher) one. This is why it is left to the NEA server=B9s policy to determine if it is willing to accept a lower version or not.=20 Thanks again, Nancy. --B_3414166178_74033928 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable RE:[Nea] NEA WG Next Steps: Call for Comments on PT-EAP I-D Hi Carolin,

For some reason I can not respond to your review directly so am sending to = the NEA
Reflector...Thanks for taking the time to review the PT-EAP draft and provi= de comments.
I’ve incorporated all your suggested updates in the latest draft-ietf= -nea-pt-eap-01
Draft.

To your question:
Section 3.2

- "The NEA Client SHOULD choose the value sent by
   the NEA Server if the NEA Client supports it. However, th= e NEA Client
   MAY set the Version field to a value less than the value = sent by the
   NEA Server"

-> does this mean, the client is allowed to choose an older version even= he supports the same version like the server. Wouldn't it be better to requ= ire the client to use the version the server requested if he supports it and= only allow to use older versions if the client does not support the server'= s version?

[NCW]= Yes, the intent is to have the client negotiate the newest version it has, = but it is difficult to discern this
 and thus the server can only presume the client is negotiating a lowe= r version because it can not support a
 newer (higher) one.  This is why it is left to the NEA server= 217;s policy to determine if it is willing to accept a lower
 version or not.

Thanks again,
    Nancy. --B_3414166178_74033928-- From kathleen.moriarty@emc.com Mon Mar 12 06:09:37 2012 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 CBCF921F8748 for ; Mon, 12 Mar 2012 06:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.988 X-Spam-Level: X-Spam-Status: No, score=-9.988 tagged_above=-999 required=5 tests=[AWL=0.610, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rS-oyIa8MTVl for ; Mon, 12 Mar 2012 06:09:32 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id F08E821F870B for ; Mon, 12 Mar 2012 06:09:31 -0700 (PDT) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2CD9SEO021917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2012 09:09:29 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Mon, 12 Mar 2012 09:09:15 -0400 Received: from mxhub12.corp.emc.com (mxhub12.corp.emc.com [10.254.92.107]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q2CD9CPZ024751; Mon, 12 Mar 2012 09:09:13 -0400 Received: from mx06a.corp.emc.com ([169.254.1.82]) by mxhub12.corp.emc.com ([10.254.92.107]) with mapi; Mon, 12 Mar 2012 09:09:13 -0400 From: To: , Date: Mon, 12 Mar 2012 09:09:11 -0400 Thread-Topic: review of draft-ietf-nea-pt-eap-00.txt Thread-Index: AcziDrAE1hU3CovTTaa6IG1T1kr34gcXQZAbAHkn46A= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AE31510960917D478171C79369B660FA0E30B7170AMX06Acorpemcc_" MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [Nea] review of draft-ietf-nea-pt-eap-00.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 13:09:37 -0000 --_000_AE31510960917D478171C79369B660FA0E30B7170AMX06Acorpemcc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nancy, You are welcome, I am glad you found the comments helpful. Yes, I will be = at the meeting in Paris and we can talk more then. The responses in-line l= ook good, thank you for making the updates. I will look through the update= d draft prior to the meeting and we can discuss the outstanding items along= with any other comments. Thank you, Kathleen From: Nancy Cam-Winget [mailto:ncamwing@cisco.com] Sent: Friday, March 09, 2012 10:13 PM To: Moriarty, Kathleen; nea@ietf.org Cc: paul_sangster@symantec.com Subject: Re: review of draft-ietf-nea-pt-eap-00.txt Hi Kathleen, Many thanks for the careful review, I have tried to incorporate most of you= r comments and suggestions in the recently updated draft but had some further questions/comments belo= w (we can also discuss them at the IETF if you will be there?): On 2/2/12 4:56 PM, "kathleen.moriarty@emc.com" = wrote: Hello Nancy and Paul, I volunteered to review the draft for the working group. The document look= s very good. A number of my comments are nits and some are areas in which = the document can benefit from additional specificity. Here are my comments= : Section 3.1, could you include a diagram? I think that will help the reade= r to see the flow on first read. The text reads well, but not being famili= ar with the draft, I had to read it twice to make sure I had the background= to continue reading. It would be useful to reference while reading sectio= n 3.2 as well. [NCW] Will be happy to include a diagram but I wasn't exactly sure as to wh= ether you were looking for an PT-EAP vs. EAP-tunnel-method+PT-EAP flow or general encapsulation of PT-EAP= inside a tunnel method. If you can provide more guidance, I can make an attempt at such a diagram. Section 3.3: Just a suggestion to reword the first paragraph: In most cases, EAP-TNC fragmentation will not be required. However, PB-TNC batches can be very long and EAP message length is sometimes tightly constrained. As a result, EAP-TNC includes a fragmentation mechanism to= be used when a particular PB-TNC batch is too long to fit into a single EAP- TNC message. [NCW] Given that there was agreement that PT-EAP did not need fragmentation= I think that this and the next few comments no longer need to be addressed. Section 3.3: It would be helpful to distinguish the differences from the re= ferenced specifications so that a developer knows where this specification = differs. "The fragmentation mechanism used in EAP-TNC is quite similar to the mechanism used by EAP-TLS [17], EAP-TTLS [14], and EAP-FAST [12]. It uses the L flag (length included) and the M flag (more fragments) as well as the Data Length field." In the following paragraphs, including the references to the appropriate sp= ec where there is a match and then pointing out the difference could be use= ful. Section 3.3: Is there a reference that can be included to where one can fin= d the 'variety of reasons' in the last paragraph? "However, a NEA Server or peer still MAY decide to terminate an EAP-TNC exchange at any time for a variety of reasons." Section 3.4: Type, I had the word please in a draft :) and someone recommen= ded pulling it out and just directly making the request. You may want to d= o the same here. [NCW] The note has been removed as the Type must now be assigned by IANA. Section 3.4 Data Length: Recommend adding a comma in the first sentence and= removing two in the second: Data Length is an optional field, four octets in length. When present, it indicates the total length before fragmentation of a fragmented PB-TNC batch. [NCW] The sentence/paragraph was reworked given that there is no fragmentat= ion within PT-EAP. Section 3.5: Should 'SHOULD' be 'MUST' in the following sentence to protec= t against the attack? If this is not required of the protocol, then I sugg= est using non RFC2119 language, something like the following: To protect against NEA Asokan attacks, it is necessary for the Posture Brok= er on an EMA- equipped endpoint to pass the tls-unique channel binding [18] for PT-EAP's tunnel method to the EMA. [NCW] Updated per your suggestion. I think the following sentence should be broken into two as follows (left i= n the page information so you can find it): This value can then be included Sangster et al. Expires February 30, 2012 [Page 10] Internet-Draft PT-EAP August 2011 in the EMA's attestation and the Posture Validator responsible for communicating with the EMA. The EMA may then confirm that the value mat= ches the tls-unique channel binding for its end of the tunnel. [NCW] I've updated the text to reflect that it is the Posture Validator who= is validating the tls-unique passed by the NEA Client to the EMA. Please = let me know if it is still unclear and we can try to make further adjustmen= ts. Can you reword the following sentence (next one in this section)? It is a = little tough for me to follow: "If the values match and the integrity of the endpoint is good, the posture sent by the EMA and NEA Client is from the same endpoint as the client side of the TLS connection (since the endpoint knows the tls- unique value) so no man-in-the-middle is forwarding posture." [NCW] Reworded to "If the tls-unique values between the NEA Client and NEA = Server match endpoint, then the posture sent by the EMA (and thus the NEA C= lient) is from the same endpoint as the client side of the TLS connection = (since the endpoint knows the tls-unique value) so no man-in-the-middle is = forwarding posture." Again, please let me know if further adjustments need to be made. Security Considerations: Could you reference the documents where the securi= ty requirements exist. I like that the introduction to this section clearl= y states that these are recommendations and not the requirements, but want = o be sure the requirements are directly referenced. [NCW] RFC5209 has been added as the reference. In section 4.2.1, RFC2119 terms are used, this means they are requirements.= Is that the case? If so, you may want to have a Security Requirements se= ction prior to your Security Considerations Section and include items like = these. It is starting to become a trend in drafts so that security require= ments are not ignored by developers. This particular statement is high-lev= el, so you may want to change it to use language not defined in RFC2119, bu= t clearly point to the specification that provides the details of how the a= uthentication and other security features are provided in the introduction. [NCW] In the interest of time and discussion, I'd like to leave this one fo= r us to close at the IETF meeting. I think I'm OK moving the EAP Tunnel Security requirements but then am not = sure that would leave much in the Security Considerations....or, we could a= lso soften the language. But I would like to get others in the WG to chime in as well.... Section 4.2.2, Consider breaking the last sentence into multiple sentences. [NCW] The last sentence of the last paragraph has been split into two....pl= ease let me know if more is needed. Section 4.2.5 also contains an RFC2119 term. This is fine, just point it o= ut as you decide how to handle considerations versus requirements with the = current introductory remarks. [NCW] Again, I've put this in the general topic of "how to organized the re= quirements vs. considerations" for us to discuss at the IETF (and of course, can continue to do so in the = reflector as well). Same for 4.3: This includes a set of requirements nested inside a section t= hat says it is not requirements. Section 4.3: I think you need to be more specific and provide references to= the acceptable authentication options to have interoperability between imp= lementations. Section 4.4: I like seeing the reference to TLS, can you also include the r= eferences to EAP-FAST and EAP-TLS here so the reader has links to the RFCs = when the document is published? It could help them figure out things like = the necessary version of TLS to support, etc. I realize this is already re= ferenced higher in the document, so it is just to be helpful to the reader/= developer. [NCW] References have been added. Section 4.4: Last paragraph, this goes into authentication, but doesn't pro= vide a reference to the appropriate specs to follow either. [NCW] Added EAP-FAST and TTLS as examples (with references). Section 4.5: It may only be me, but I had to read the introductory sentenc= e a couple of times to get the context - to make sure I had it right. Can = you add 'for this specification' or something like that to the sentence? [NCW] Updated per your suggestion. Section 6: I think you can make a direct statement requesting registration = of the value. This text will live on in the document after the value is as= signed. Maybe ask IANA, but in the draft make it more direct - Registers v= alue 38... [NCW] Text has been updated to reflect that IANA must assign a new EAP valu= e. Section 6.1 looks good - I just finished similar IANA requests. [NCW] Thanks! I am just in the NEA-digest list, so if you would like me to see it right a= way, you may want to copy me directly. Thank you, Kathleen --_000_AE31510960917D478171C79369B660FA0E30B7170AMX06Acorpemcc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: review of draft-ietf-nea-pt-eap-0= 0.txt

Hi Nancy,=

 <= /p>

You are welcome, I am glad you found the com= ments helpful.  Yes, I will be at the meeting in Paris and we can talk= more then.  The responses in-line look good, thank you for making the= updates.  I will look through the updated draft prior to the meeting = and we can discuss the outstanding items along with any other comments.

 

<= p class=3DMsoNormal>Thank you,

Kathleen

 

From: Nancy Cam-= Winget [mailto:ncamwing@cisco.com]
Sent: Friday, March 09, 2012 = 10:13 PM
To: Moriarty, Kathleen; nea@ietf.org
Cc: paul_= sangster@symantec.com
Subject: Re: review of draft-ietf-nea-pt-ea= p-00.txt

 <= /o:p>

Hi Kathleen,

Many thanks for the = careful review, I have tried to incorporate most of your comments and sugge= stions
 in the recently updated draft but had some further question= s/comments below (we can also discuss
 them at the IETF if you will= be there?):


On 2/2/12 4:56 PM, "kathleen.moriarty@emc.com" <kathleen.moriarty@emc.com> wrote:
 

Hello Nancy and = Paul,

I volunteered to review the draft for the working group.  = ;The document looks very good.  A number of my comments are nits and s= ome are areas in which the document can benefit from additional specificity= .  Here are my comments:

Section 3.1, could you include a diagr= am?  I think that will help the reader to see the flow on first read. =  The text reads well, but not being familiar with the draft, I had to = read it twice to make sure I had the background to continue reading.  = It would be useful to reference while reading section 3.2 as well.
[NCW] Will be happy to include a diagram but I wasn&#= 8217;t exactly sure as to whether you were looking for an
PT-EAP vs. EAP= -tunnel-method+PT-EAP flow or general encapsulation of PT-EAP inside a tunn= el method.
If you can provide more guidance, I can make an attempt at su= ch a diagram.

Section 3.3: Just a suggestion to reword the fi= rst paragraph:
In most cases, EAP-TNC fragmentation will not be required= . However, PB-TNC
   batches can be very long and EAP mes= sage length is sometimes tightly
   constrained.  As= a result, EAP-TNC includes a fragmentation mechanism to be used
 &= nbsp; when a particular PB-TNC batch is too long to fit into a single = EAP-
   TNC message.
[NCW] = Given that there was agreement that PT-EAP did not need fragmentation I thi= nk that this
and the next few comments no longer need to be addressed.
Section 3.3: It would be helpful to distinguish the difference= s from the referenced specifications so that a developer knows where this s= pecification differs.

"The fragmentation mechanism used in EAP-= TNC is quite similar to the
   mechanism used by EAP-TLS = [17], EAP-TTLS [14], and EAP-FAST [12]. It
   uses the L = flag (length included) and the M flag (more fragments) as
  &n= bsp;well as the Data Length field."

In the following paragraphs= , including the references to the appropriate spec where there is a match a= nd then pointing out the difference could be useful.

Section 3.3: Is= there a reference that can be included to where one can find the 'variety = of reasons' in the last paragraph?
"However, a
   = ;NEA Server or peer still MAY decide to terminate an EAP-TNC exchange
&n= bsp;  at any time for a variety of reasons."

Section = 3.4: Type, I had the word please in a draft :) and someone recommended pull= ing it out and just directly making the request.  You may want to do t= he same here.
[NCW] The note has been removed= as the Type must now be assigned by IANA.

Section 3.4 Data L= ength: Recommend adding a comma in the first sentence and removing two in t= he second:
Data Length is an optional field, four octets in length. When= present, it
      indicates the total len= gth before fragmentation of a fragmented
     &= nbsp;PB-TNC batch.
[NCW] The sentence/paragra= ph was reworked given that there is no fragmentation within PT-EAP.

Section 3.5:  Should 'SHOULD' be 'MUST' in the following senten= ce to protect against the attack?  If this is not required of the prot= ocol, then I suggest using non RFC2119 language, something like the followi= ng:
To protect against NEA Asokan attacks, it is necessary for the Postu= re Broker on an EMA-
   equipped endpoint to pass the tls= -unique channel binding [18] for
   PT-EAP's tunnel metho= d to the EMA.
[NCW] Updated per your suggesti= on.

I think the following sentence should be broken into two = as follows (left in the page information so you can find it):
This value= can then be included


Sangster et al.     &n= bsp; Expires February 30, 2012       &nb= sp;       [Page 10]

Internet-Draf= t             &= nbsp;    PT-EAP       &nb= sp;            =   August 2011


   in the EMA's attestati= on and the Posture Validator responsible for
   communica= ting with the EMA.  The EMA may then confirm that the value matches   the tls-unique channel binding for its end of the tunnel= .
[NCW] I’ve updated the text to reflec= t that it is the Posture Validator who is validating the tls-unique passed = by the NEA Client to the EMA.  Please let me know if it is still uncle= ar and we can try to make further adjustments.


Can you re= word the following sentence (next one in this section)?  It is a littl= e tough for me to follow:
"If the
   values match= and the integrity of the endpoint is good, the posture
  &nbs= p;sent by the EMA and NEA Client is from the same endpoint as the
 =   client side of the TLS connection (since the endpoint knows the= tls-
   unique value) so no man-in-the-middle is forward= ing posture."
[NCW] Reworded to ̶= 0;If the tls-unique values between the NEA Client and NEA Server match endp= oint, then the posture sent by the EMA (and thus the NEA Client) is from th= e same endpoint as the client side of the TLS connection  (since the e= ndpoint knows the tls-unique value) so no man-in-the-middle is forwarding p= osture.”
Again, please let me know if further adjustments need= to be made.


Security Considerations: Could you reference= the documents where the security requirements exist.  I like that the= introduction to this section clearly states that these are recommendations= and not the requirements, but want o be sure the requirements are directly= referenced.
[NCW] RFC5209 has been added as = the reference.

In section 4.2.1, RFC2119 terms are used, this= means they are requirements.  Is that the case?  If so, you may = want to have a Security Requirements section prior to your Security Conside= rations Section and include items like these.  It is starting to becom= e a trend in drafts so that security requirements are not ignored by develo= pers.  This particular statement is high-level, so you may want to cha= nge it to use language not defined in RFC2119, but clearly point to the spe= cification that provides the details of how the authentication and other se= curity features are provided in the introduction.
[NCW] In the interest of time and discussion, I’d like to leave = this one for us to close at the IETF meeting.
I think I’m OK movin= g the EAP Tunnel Security requirements but then am not sure that would leav= e much in the Security Considerations....or, we could also soften the langu= age.  But I would like to get others in the WG to
chime in as well.= ...

Section 4.2.2, Consider breaking the last sentence into m= ultiple sentences.
[NCW] The last sentence of= the last paragraph has been split into two....please let me know if more i= s needed.

Section 4.2.5 also contains an RFC2119 term.  = This is fine, just point it out as you decide how to handle considerations = versus requirements with the current introductory remarks.
[NCW] Again, I’ve put this in the general topic of &#= 8220;how to organized the requirements vs. considerations”
for us = to discuss at the IETF (and of course, can continue to do so in the reflect= or as well).

Same for 4.3: This includes a set of requirement= s nested inside a section that says it is not requirements.

Section = 4.3: I think you need to be more specific and provide references to the acc= eptable authentication options to have interoperability between implementat= ions.

Section 4.4: I like seeing the reference to TLS, can you also = include the references to EAP-FAST and EAP-TLS here so the reader has links= to the RFCs when the document is published?  It could help them figur= e out things like the necessary version of TLS to support, etc.  I rea= lize this is already referenced higher in the document, so it is just to be= helpful to the reader/developer.
[NCW] Refer= ences have been added.

Section 4.4: Last paragraph, this goes= into authentication, but doesn't provide a reference to the appropriate sp= ecs to follow either.
[NCW] Added EAP-FAST an= d TTLS as examples (with references).

Section 4.5:  It m= ay only be me, but I had to read the introductory sentence a couple of time= s to get the context - to make sure I had it right.  Can you add 'for = this specification' or something like that to the sentence?
[NCW] Updated per your suggestion.

Section 6:= I think you can make a direct statement requesting registration of the val= ue.  This text will live on in the document after the value is assigne= d.  Maybe ask IANA, but in the draft make it more direct - Registers v= alue 38...
[NCW] Text has been updated to ref= lect that IANA must assign a new EAP value.

Section 6.1 looks= good - I just finished similar IANA requests.
[NCW] Thanks!


I am just in the NEA-digest list, so if y= ou would like me to see it right away, you may want to copy me directly.
Thank you,
Kathleen



= --_000_AE31510960917D478171C79369B660FA0E30B7170AMX06Acorpemcc_-- From shanna@juniper.net Tue Mar 13 13:35:09 2012 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 4F13921F8571 for ; Tue, 13 Mar 2012 13:35:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxroBQUxtbqY for ; Tue, 13 Mar 2012 13:35:08 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED7921F8627 for ; Tue, 13 Mar 2012 13:35:08 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT1+ve16uC3k4Jr7kwMAQ454NoebNtmGA@postini.com; Tue, 13 Mar 2012 13:35:08 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 13 Mar 2012 13:34:48 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 13 Mar 2012 13:34:48 -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; Tue, 13 Mar 2012 16:34:47 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Tue, 13 Mar 2012 16:34:45 -0400 Thread-Topic: WGLC Comments on PT-TLS Thread-Index: Ac0BWLpWqBvcbGM7QFSlg9Gii3azgw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629 Subject: [Nea] WGLC Comments on PT-TLS 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, 13 Mar 2012 20:35:09 -0000 I have a few minor comments on the latest version of PT-TLS (draft-ietf-nea-pt-tls-02.txt). Overall, I think this document is quite solid and ready to go to the IESG. If you agree (or if you don't), please respond to the WGLC. Short responses are fine. * In section 3.1.1, the sentence that starts with "This means the NEA Client" is repeated. * In section 3.4.2, "Set-up" should be "Setup" and "protect again" should be "protect against". * In section 3.6 under SASL Mechanisms, what is the meaning of the phrase "at another time"? Other than what? Is this message only supposed to be sent at a particular time? If so, we should say that somewhere. If not, we should probably remove the requirement for the NEA Client to send an Invalid Message error code in this circumstance. Thanks, Steve From shanna@juniper.net Mon Mar 19 13:17:56 2012 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 3716221E8013 for ; Mon, 19 Mar 2012 13:17:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLUoitqDY6kW for ; Mon, 19 Mar 2012 13:17:55 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFF721E800C for ; Mon, 19 Mar 2012 13:17:55 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT2eUcl7FTJfMFlaQFHLxqtTYzhiJoL+n@postini.com; Mon, 19 Mar 2012 13:17:55 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.3.213.0; Mon, 19 Mar 2012 13:16:36 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 19 Mar 2012 16:16:35 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Mon, 19 Mar 2012 16:16:33 -0400 Thread-Topic: [Nea] Asokan attack draft Thread-Index: Acz+Vs2pVpAy4X6TSbGUvQaezEghqAADVxogAenequA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Nea] Asokan attack draft X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 20:17:56 -0000 As promised below, Joe and I updated the NEA Asokan draft so that it's up-to-date. The new draft is available online at http://www.ietf.org/internet-drafts/draft-salowey-nea-asokan-01.txt Please look it over and send comments to this email list. We're not going to call a WGLC now since we already have two under way but we will be discussing this draft at the NEA WG meeting next week so it would be great to get some comments before then. At least, you'll want to come to the meeting with a clue about it. At the last NEA WG meeting (at IETF 82), we all agreed that it would be best to have this document become a WG draft. If you have any concerns about this course of action, please speak up. Otherwise, we'll repost it after IETF 82 as a WG draft and plan to start a WGLC for it then. After WG consensus is reached on the draft, we'll send it to the IESG for Informational status. BTW, our AD has indicated that there's no need to update our charter to add this document because it's effectively just a part of the PT-EAP and PT-TLS Security Considerations sections. And it doesn't have any normative text. It's just a description of the NEA Asokan attack and of appropriate countermeasures, which are implemented in PT-EAP and PT-TLS. Those documents will point at the NEA Asokan Attack Analysis instead of including duplicate text in their Security Considerations sections, explaining the same attack and countermeasures twice. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Friday, March 09, 2012 9:26 PM > To: Joe Salowey; nea@ietf.org > Subject: Re: [Nea] Asokan attack draft >=20 > Yes, Joe. I agree. The Asokan attack does have broader implications > beyond NEA but explaining and analyzing those properly would require > the active involvement of at least the EMU WG. They're quite busy so > doing this would slow down the completion of the NEA WG's efforts. > Anyway, the original Asokan paper does a good job of explaining the > implications for tunnel EAP methods. However, it doesn't explain the > implications for endpoint assessment. That's the special value of > this draft. >=20 > I'll update the NEA Asokan draft so that it's up-to-date (adding > references to PT-EAP and PT-TNC, etc.) and submit that updated > version before Monday's non-00 deadline. The NEA WG can discuss > this more and decide whether we want to take that on as WG draft > headed for Informational status or to have us submit it as an > AD-sponsored submission or whatever. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > > Joe Salowey > > Sent: Friday, March 09, 2012 7:43 PM > > To: nea@ietf.org > > Subject: [Nea] Asokan attack draft > > > > We had some previous discussion on expanding the scope of the Asokan > > draft to beyond the NEA scenario. The looks to involve a fair amount > > of work to cover the general case. I'm thinking that focusing on and > > how the Asokan attack applies to NEA and how it is mitigated in NEA > > would be much better bounded and some thing we could complete more > > quickly. > > > > Comments? > > > > Thanks, > > > > Joe > > _______________________________________________ > > 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 Mon Mar 19 13:48:09 2012 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 ED35B21F876D for ; Mon, 19 Mar 2012 13:48:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzcYP-2qU13F for ; Mon, 19 Mar 2012 13:48:09 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA0921F875B for ; Mon, 19 Mar 2012 13:48:09 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT2ebiAW/l4MeYbr85L2+5m2XEeobep8m@postini.com; Mon, 19 Mar 2012 13:48:09 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.3.213.0; Mon, 19 Mar 2012 13:47:00 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 19 Mar 2012 16:46:59 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Mon, 19 Mar 2012 16:46:57 -0400 Thread-Topic: WGLC Comments on PT-EAP Thread-Index: Ac0GEWyXX8IvJaOlQAeOUr5M5u/xEQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Nea] WGLC Comments on PT-EAP X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 20:48:10 -0000 Here are my comments on draft-ietf-nea-pt-eap-01.txt. I have divided these comments into substantive ones and typos. I don't think any of these comments will be controversial but please review them and see what you think. If you disagree, please speak up. Also, I'd like to ask all NEA WG participants to PLEASE look over the PT-EAP and PT-TLS specs and send comments to the nea@ietf.org email list. These documents are in WGLC. As a WG participant, it's your responsibility to review the documents and send your comments to the list. Even just saying "Good with me" or "OK" is fine but you shouldn't abdicate your duty by letting the documents fly by without even looking at them. Thanks, Steve ---------- Substantive Comments on draft-ietf-nea-pt-eap-01.txt * There's no need for the L bit or the Data Length field since we have removed fragmentation. The recipient of a PT-EAP message can determine the length of that message by just looking at the EAP Length field. * In the last sentence on page 8, "match endpoint" should be "match and this is confirmed by the EMA". In order to prevent a NEA Asokan attack, the server needs to confirm that the EMA has the same tls-unique value. Another way to clarify this would be to change the words "NEA Client" where they first appear in that sentence to "EMA". * In section 4.2.2, I think that "Similarly" should be "Therefore". This better explains the causality between hiding the PT-EAP method and increasing the difficulty for a passive MITM to tamper with the method. However, this argument is fairly weak since the PT-EAP method might always occur at the same offset in the exchange. Probably it would be better to just remove the last two sentences in this paragraph lest they give a false understanding of the protections that prevent a MITM from inserting falsified messages without detection. Those protections reside primarily in integrity protection and authentication not in encryption. * In section 4.5, the claim for Fragmentation should be "No" since that has been removed from this draft. * Could you please add my name to the Acknowledgments section? I did write the original version of this draft. Typos in draft-ietf-nea-pt-eap-01.txt * In the abstract, the first sentence should say "in a TLS protected tunnel method" not just "in TLS protected tunnel method". The difference here is adding the word "a". * In the next sentence, delete "As such". It doesn't really add anything. * In the last sentence of the first paragraph of the Introduction, change "The PT protocol must" to "The PT-EAP protocol must". That requirement doesn't apply to PT-TLS (i.e. PT-TLS needn't be protected by an outer tunnel because it already includes one). * The heading at the start of section 3 should begin with a capital D not a lower case d. * In the last sentence on page 8, the word "between" should be the word "of". * In section 4 (just before section 4.1), the phrase "requirements for the NEA" should be just "requirements for NEA". * In section 4.4, please insert a space after "[RFC5281]". This happens twice in that section. * In section 4.5, delete the comma after the word "claims" in the first sentence. It's unneeded and confusing. Also, there are problems with the indentation of the table of claims in this section. From latze@angry-red-pla.net Sun Mar 25 13:39:25 2012 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 63B5421E801B for ; Sun, 25 Mar 2012 13:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-HpoST22aG9 for ; Sun, 25 Mar 2012 13:39:24 -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 4A37121E801A for ; Sun, 25 Mar 2012 13:39:24 -0700 (PDT) Received: from [93.158.44.40] (helo=[10.216.47.12]) by thuvia.angry-red-pla.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SBuDh-0001ur-JQ for nea@ietf.org; Sun, 25 Mar 2012 22:39:22 +0200 Message-ID: <4F6F8274.5090807@angry-red-pla.net> Date: Sun, 25 Mar 2012 22:39:16 +0200 From: Carolin Latze User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11 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] WGLC Comments on PT-EAP 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: Sun, 25 Mar 2012 20:39:25 -0000 Sorry for the late reply, but here are my (minor) comments: - On the authors names, Nancy is listed with full name, Paul just with family name - in the Introduction it is written that there is another PT protocol to run on top of IP. Maybe it would make sense to put a reference to PT-TLS? Just in case the reader wants to know the details on this protocol. - Section 2: Since you talked about TLS-based tunnel methods before, you might want to add a "like TLS" to the last sentence. - "3. definition of PT-EAP" -> capital "D" - Section 3.4: In the sections before, you said PT-EAP could run over a TLS-based tunnel or one with comparable features. However, the channel bindings solution is only for TLS, right? So maybe, we need another sentence there, mentioning how to do this for other tunnel methods - Section 4.1.1: "Expose the authenticated identity of the Posture Transport Server" -> " ... to the Posture Broker Client only" ? - Section 4.1.2: same just for the server - Section 4.4: "EAP-FAST [RFC4851] and EAP-TTLS [RFC5281]make use of TLS [RFC5246] to" -> space missing after [RFC5281] - " With all these methods (e.g. EAP-FAST [RFC4851] and EAP-TTLS [RFC5281], a cryptographic key is derived from the authentication..." -> closing ")" is missing Regards Carolin On 03/19/2012 09:46 PM, Stephen Hanna wrote: > Here are my comments on draft-ietf-nea-pt-eap-01.txt. > I have divided these comments into substantive ones > and typos. I don't think any of these comments will > be controversial but please review them and see what > you think. If you disagree, please speak up. > > Also, I'd like to ask all NEA WG participants to > PLEASE look over the PT-EAP and PT-TLS specs and > send comments to the nea@ietf.org email list. > These documents are in WGLC. As a WG participant, > it's your responsibility to review the documents > and send your comments to the list. Even just saying > "Good with me" or "OK" is fine but you shouldn't > abdicate your duty by letting the documents fly by > without even looking at them. > > Thanks, > > Steve > > ---------- > > Substantive Comments on draft-ietf-nea-pt-eap-01.txt > > * There's no need for the L bit or the Data Length field > since we have removed fragmentation. The recipient of > a PT-EAP message can determine the length of that message > by just looking at the EAP Length field. > > * In the last sentence on page 8, "match endpoint" > should be "match and this is confirmed by the EMA". > In order to prevent a NEA Asokan attack, the server > needs to confirm that the EMA has the same tls-unique > value. Another way to clarify this would be to change > the words "NEA Client" where they first appear in > that sentence to "EMA". > > * In section 4.2.2, I think that "Similarly" should be > "Therefore". This better explains the causality between > hiding the PT-EAP method and increasing the difficulty > for a passive MITM to tamper with the method. However, > this argument is fairly weak since the PT-EAP method > might always occur at the same offset in the exchange. > Probably it would be better to just remove the last > two sentences in this paragraph lest they give a false > understanding of the protections that prevent a MITM > from inserting falsified messages without detection. > Those protections reside primarily in integrity > protection and authentication not in encryption. > > * In section 4.5, the claim for Fragmentation should be > "No" since that has been removed from this draft. > > * Could you please add my name to the Acknowledgments > section? I did write the original version of this draft. > > Typos in draft-ietf-nea-pt-eap-01.txt > > * In the abstract, the first sentence should say "in > a TLS protected tunnel method" not just "in TLS > protected tunnel method". The difference here is > adding the word "a". > > * In the next sentence, delete "As such". It doesn't > really add anything. > > * In the last sentence of the first paragraph of the > Introduction, change "The PT protocol must" to "The > PT-EAP protocol must". That requirement doesn't apply > to PT-TLS (i.e. PT-TLS needn't be protected by an > outer tunnel because it already includes one). > > * The heading at the start of section 3 should begin > with a capital D not a lower case d. > > * In the last sentence on page 8, the word "between" > should be the word "of". > > * In section 4 (just before section 4.1), the phrase > "requirements for the NEA" should be just "requirements > for NEA". > > * In section 4.4, please insert a space after "[RFC5281]". > This happens twice in that section. > > * In section 4.5, delete the comma after the word "claims" > in the first sentence. It's unneeded and confusing. > Also, there are problems with the indentation of the > table of claims in this section. > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > From latze@angry-red-pla.net Sun Mar 25 14:15:57 2012 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 6B3AC21F844F for ; Sun, 25 Mar 2012 14:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhriySfuUeYC for ; Sun, 25 Mar 2012 14:15:56 -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 C266821F844B for ; Sun, 25 Mar 2012 14:15:56 -0700 (PDT) Received: from [93.158.44.40] (helo=[10.216.47.12]) by thuvia.angry-red-pla.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SBun3-0001x9-Pd for nea@ietf.org; Sun, 25 Mar 2012 23:15:55 +0200 Message-ID: <4F6F8B04.7060504@angry-red-pla.net> Date: Sun, 25 Mar 2012 23:15:48 +0200 From: Carolin Latze User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11 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] WGLC Comments on PT-TLS 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: Sun, 25 Mar 2012 21:15:57 -0000 few minor comments from my side: - Introduction: Same as with PT-EAP: it is mentioned that there is another PT protocol. Maybe it makes sense to reference PT-EAP here? - Section 3.4.1: new (empty) line missing before first point - Section 3.4.2: same - Section 3.5, Message Identifier: "This value can be copied into the body of a response message to indicate which message was received and caused the response" -> can or SHOULD? I'd prefer a "SHOULD" in order to make people implement it as a useful feature. Or was there a reason behind the "can"? Regards Carolin On 03/13/2012 09:34 PM, Stephen Hanna wrote: > I have a few minor comments on the latest version of PT-TLS > (draft-ietf-nea-pt-tls-02.txt). > > Overall, I think this document is quite solid and ready to > go to the IESG. If you agree (or if you don't), please > respond to the WGLC. Short responses are fine. > > * In section 3.1.1, the sentence that starts with "This means > the NEA Client" is repeated. > > * In section 3.4.2, "Set-up" should be "Setup" and "protect > again" should be "protect against". > > * In section 3.6 under SASL Mechanisms, what is the meaning > of the phrase "at another time"? Other than what? Is this > message only supposed to be sent at a particular time? > If so, we should say that somewhere. If not, we should > probably remove the requirement for the NEA Client to > send an Invalid Message error code in this circumstance. > > Thanks, > > Steve > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > From ietf@meetecho.com Tue Mar 27 07:47:37 2012 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 AAE0B21F8613 for ; Tue, 27 Mar 2012 07:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.892 X-Spam-Level: X-Spam-Status: No, score=-0.892 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8g23i9-0HyE for ; Tue, 27 Mar 2012 07:47:37 -0700 (PDT) Received: from smtplq03.aruba.it (smtplqs-out29.aruba.it [62.149.158.69]) by ietfa.amsl.com (Postfix) with SMTP id B09A421F8607 for ; Tue, 27 Mar 2012 07:47:33 -0700 (PDT) Received: (qmail 21945 invoked by uid 89); 27 Mar 2012 14:47:31 -0000 Received: from unknown (HELO smtp1.aruba.it) (62.149.158.221) by smtplq03.aruba.it with SMTP; 27 Mar 2012 14:47:31 -0000 Received: (qmail 32443 invoked by uid 89); 27 Mar 2012 14:47:31 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp1.ad.aruba.it with SMTP; 27 Mar 2012 14:47:31 -0000 Message-ID: <4F71D301.3090009@meetecho.com> Date: Tue, 27 Mar 2012 16:47:29 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: Nea@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp1.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq03.aruba.it 1.6.2 0/1000/N Cc: Team Meetecho Subject: [Nea] Meetecho support for NEA WG meeting session 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, 27 Mar 2012 14:47:37 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Wednesday's NEA WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf83/nea The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to, by either calling a landline phone number, or using our embedded VoIP applet (in this last case they are *strongly* advised to use a headset). A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf83/tutorials Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From sethomso@cisco.com Wed Mar 28 02:29:04 2012 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 3DD8C21F8838 for ; Wed, 28 Mar 2012 02:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.399 X-Spam-Level: X-Spam-Status: No, score=-109.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFsKV-1qnqpd for ; Wed, 28 Mar 2012 02:29:03 -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 8C3F921F8826 for ; Wed, 28 Mar 2012 02:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=1849; q=dns/txt; s=iport; t=1332926943; x=1334136543; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=mqDg3DIQY28NnpQZR3u05FRZTwERgyOxaoMaN9YYitE=; b=EddI8F4uyVyeaya8DOZk4Io/vDWjfo6nbvo9QLv8jzjSj+1yX08qGRmW zI/cb6jrC1CHMOgpRsolx0MgUl72Z5vNrtj2MnRINkl6I6CJ9HXaFAvOz M7leFTzYto8RkH+N1Ijbo28eKvx4g8ex/QLya9NTodblF7W6HESbvCokS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAXZck+tJXG//2dsb2JhbABFuG2BB4ILAQQSAScCAU4BgSYBBC4Hh2iaFYEnnw+NboMkBJVhjkWBaIMD X-IronPort-AV: E=Sophos;i="4.73,661,1325462400"; d="scan'208";a="70037747" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 28 Mar 2012 09:29:03 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2S9T3PE013451 for ; Wed, 28 Mar 2012 09:29:03 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Mar 2012 04:29:02 -0500 Received: from 10.86.249.18 ([10.86.249.18]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 28 Mar 2012 09:29:02 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 28 Mar 2012 05:29:02 -0400 From: Susan Thomson To: Message-ID: Thread-Topic: Comments on PT-TLS Thread-Index: Ac0MxTYj7Z6ESsKGUUiZqPqo8zpzIg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 28 Mar 2012 09:29:02.0867 (UTC) FILETIME=[36A7CE30:01CD0CC5] Subject: [Nea] Comments on PT-TLS X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 09:29:04 -0000 Some comments on PT-TLS I-D. Apologies for delay. Susan ------------ Section 3.4.2.3: "Once a PT-TLS session is available to carry NEA assessments, either the Posture Transport Client or Server can start an assessment when provided a PB-TNC batch for transmission. " I believe PB-TNC states that the initiator of the transport connection is the one to start the first assessment (while subsequent assessments may be started by either party). I think the sentence should be clarified to say that. Section 3.8.3: Assume the NEA Client initiates the PT-TLS session, and will be starting the assessment. The NEA Client has no way of knowing whether the server requires SASL authentication or not. Hence, in the case when the server does require client authentication, it will start the assessment and receive an error. An alternate solution would be to require the NEA server to send the SASL mechanisms TLV (empty in the case no authn is required) - this usage is documented in the spec, but I don't think it is a MUST. This means the client can wait for this message before starting an assessment, avoiding the error msg above. What is the intended operation? The second is probably better since it avoids spurious error messages. Section 3.8.2: 1st 2 sentences still refers to client sending SASL Request Mechanisms msg/TLV. Needs to be clarified for new flow. Section 3.4.2.2: Is initiation of SASL exchange only supported from the NEA Server (regardless of whether NEA Server is PT-TLS Initiator or PT-TLS Responder)? The 3rd para implies this, but it could be made explicit in 2nd paragraph. Section 3.8.8 and 3.8.10: The description associated with optional fields should be referring to NEA Server, not PT-TLS Responder (assuming NEA Server always initiates SASL exchange).