From internet-drafts@ietf.org Tue Aug 7 13:35: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 EAE4B21F86B3; Tue, 7 Aug 2012 13:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 7Cpd7c1h1eVa; Tue, 7 Aug 2012 13:35:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D762B21F8672; Tue, 7 Aug 2012 13:35:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120807203554.13962.76911.idtracker@ietfa.amsl.com> Date: Tue, 07 Aug 2012 13:35:54 -0700 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-tls-07.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 20:35: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 Group= 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-07.txt Pages : 44 Date : 2012-08-07 Abstract: 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-nea-pt-tls-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-nea-pt-tls-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Paul_Sangster@symantec.com Tue Aug 7 13:39:13 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 0D5DB21F86D5 for ; Tue, 7 Aug 2012 13:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 72dp1AMMHq6S for ; Tue, 7 Aug 2012 13:39:12 -0700 (PDT) Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4784521F86D0 for ; Tue, 7 Aug 2012 13:39:12 -0700 (PDT) X-AuditID: a66201d1-b7fc36d000006755-e6-50217ceb61ab Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by ecl1mtaoutpex01.symantec.com (Symantec Messaging Gateway) with SMTP id C6.3A.26453.BEC71205; Tue, 7 Aug 2012 20:39:07 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1SyqYV-00043U-5m for nea@ietf.org; Tue, 07 Aug 2012 20:39:07 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([172.24.185.246]) with mapi; Tue, 7 Aug 2012 13:39:07 -0700 From: Paul Sangster To: "nea@ietf.org" Date: Tue, 7 Aug 2012 13:39:40 -0700 Thread-Topic: Updated PT-TLS I-D Thread-Index: Ac103MTG5WNCyPFkSnyt44oDYGsdMg== Message-ID: <6E79D623502C70419A9EAB18E4D274252B8D0BBE81@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> 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_6E79D623502C70419A9EAB18E4D274252B8D0BBE81TUS1XCHEVSPIN_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42I5sOKaju7rGsUAg1Wdqhaf31Y4MHosWfKT KYAxissmJTUnsyy1SN8ugSvjzv4LTAWvuCrW713K2MC4nrOLkZNDQsBE4vWtn0wQtpjEhXvr 2boYuTiEBF4zSjzqe8gO4fxjlDgy5TxUZiWjxKX2SewgLWwCBhI7j5wCs0UEFCU2X1wJNopF QEViZXc/G4gtLCAtMbXpHRNEjYLE6S/3oer1JKZ8vssMYvMKRElsfLoRzGYEOuP7qTVg9cwC 4hK3nsyHOk9AYsme88wQtqjEy8f/WCHqRSXutK9n7GLkAKrPl+j/6AcxUlDi5MwnLBMYhWch mTQLoWoWkiqIEh2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNManKOYW5JYn5pSUFqhYGh XnFlbiIwZpL1kvNzNzEC42ZZEuPFHYwXDuseYhTgYFTi4b2cpRggxJpYBlR5iFGCg1lJhPfw ToUAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwXdm31FxJITyxJzU5NLUgtgskycXBKNTCuunVL MuuxQN0kY+UP01+WOuRYmHwOX7Co6SPP8uY7X9nOpqzanygy+7XC5TDmfzfudIXfPGnOcejd eY9L6bFLvly+kbpGZDLbyc9Z9gtfnRflYjmloFrIFewUnVDfdN3l5sKSvU/OT+CIDyj8/5bx XNSf15pGsg3z/2WEzWh0y+hcXvdx92UnJZbijERDLeai4kQAqA0FrpcCAAA= Subject: [Nea] Updated PT-TLS I-D X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 20:39:13 -0000 --_000_6E79D623502C70419A9EAB18E4D274252B8D0BBE81TUS1XCHEVSPIN_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since our request for an early TCP port allocation was approved, the IANA h= as assigned us TCP port 271 for use with "pt-tls". I've updated and posted= PT-TLS version -07 to include this specific port number and adjusted the t= ext accordingly. --_000_6E79D623502C70419A9EAB18E4D274252B8D0BBE81TUS1XCHEVSPIN_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Since our request for an early TCP port allocation was approved, the I= ANA has assigned us TCP port 271 for use with “pt-tls”.  I= ’ve updated and posted PT-TLS version -07 to include this specific po= rt number and adjusted the text accordingly.
 
 --_000_6E79D623502C70419A9EAB18E4D274252B8D0BBE81TUS1XCHEVSPIN_-- From shanna@juniper.net Fri Aug 17 19:30:49 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 8B9CF11E808A for ; Fri, 17 Aug 2012 19:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.589 X-Spam-Level: X-Spam-Status: No, score=-106.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vng+OHRFMwgh for ; Fri, 17 Aug 2012 19:30:49 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 088D011E808E for ; Fri, 17 Aug 2012 19:30:46 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUC7+VSgQb5CXj/wybih/HfqpzUN/DYQY@postini.com; Fri, 17 Aug 2012 19:30:49 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 17 Aug 2012 19:26:17 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 17 Aug 2012 22:26:16 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Fri, 17 Aug 2012 22:26:15 -0400 Thread-Topic: Second WGLC on PT-EAP Thread-Index: Ac186NdqwChtsxe+R2q7aP/3S2DmsQ== 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] Second WGLC 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: Sat, 18 Aug 2012 02:30:49 -0000 Now that the emu working group has conducted a review of PT-EAP and the resulting changes have been discussed on the nea list and a revised draft has been published with these changes integrated, I'd like to call for one more WGLC on the draft to verify that we have consensus on it and that we're ready to send it on to the IESG. If you haven't read the PT-EAP draft before, please do so at http://www.ietf.org/id/draft-ietf-nea-pt-eap-03.txt If you have read a previous draft, you can find diffs at http://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap/history But in any case, please email the nea list with your view on whether this draft is ready to go to the IESG and then on to Proposed Standard status. If you think so, a simple "YES" will suffice. If you think not, please supply some rationale and proposed changes. This WGLC will close in a bit more than two weeks at 0800 GMT on Saturday, September 1, 2012. Thanks, Steve From latze@angry-red-pla.net Sun Aug 19 09:41:03 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 48ABB21F8539 for ; Sun, 19 Aug 2012 09:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCmPxjr4X2zt for ; Sun, 19 Aug 2012 09:41:01 -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 2932C21F8522 for ; Sun, 19 Aug 2012 09:41:00 -0700 (PDT) Received: from 117-178.104-92.cust.bluewin.ch ([92.104.178.117] helo=[192.168.1.178]) by thuvia.angry-red-pla.net with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1T38Ya-0006tJ-0Z for nea@ietf.org; Sun, 19 Aug 2012 18:40:56 +0200 Message-ID: <50311712.6060508@angry-red-pla.net> Date: Sun, 19 Aug 2012 18:40:50 +0200 From: Carolin Latze User-Agent: Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20120714 Thunderbird/14.0 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] Second WGLC 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, 19 Aug 2012 16:41:03 -0000 YES :-) On 08/18/2012 04:26 AM, Stephen Hanna wrote: > Now that the emu working group has conducted a review of > PT-EAP and the resulting changes have been discussed on > the nea list and a revised draft has been published with > these changes integrated, I'd like to call for one more > WGLC on the draft to verify that we have consensus on it > and that we're ready to send it on to the IESG. > > If you haven't read the PT-EAP draft before, please do so > at http://www.ietf.org/id/draft-ietf-nea-pt-eap-03.txt > > If you have read a previous draft, you can find diffs at > http://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap/history > > But in any case, please email the nea list with your view > on whether this draft is ready to go to the IESG and then > on to Proposed Standard status. If you think so, a simple > "YES" will suffice. If you think not, please supply some > rationale and proposed changes. > > This WGLC will close in a bit more than two weeks at > 0800 GMT on Saturday, September 1, 2012. > > Thanks, > > Steve > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From internet-drafts@ietf.org Wed Aug 22 07:56: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 1986D21F8599; Wed, 22 Aug 2012 07:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NShhvrgzRDt; Wed, 22 Aug 2012 07:56:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9391521F859B; Wed, 22 Aug 2012 07:56:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120822145617.12371.69756.idtracker@ietfa.amsl.com> Date: Wed, 22 Aug 2012 07:56:17 -0700 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-asokan-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: Wed, 22 Aug 2012 14:56:22 -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 Group= of the IETF. Title : NEA Asokan Attack Analysis Author(s) : Joseph Salowey Steve Hanna Filename : draft-ietf-nea-asokan-01.txt Pages : 8 Date : 2012-08-22 Abstract: The Network Endpoint Assessment protocols are subject to a subtle forwarding attack that has become known as the NEA Asokan Attack. This document describes the attack and countermeasures that may be mounted. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-nea-asokan There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-nea-asokan-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-nea-asokan-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shanna@juniper.net Mon Aug 27 04:06:00 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 D058021F862A for ; Mon, 27 Aug 2012 04:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15rZrAWtPscY for ; Mon, 27 Aug 2012 04:05:59 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id C357B21F858A for ; Mon, 27 Aug 2012 04:05:59 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUDtUlyMsDrfjEoPeEbmC0pJoQ95pFjV5@postini.com; Mon, 27 Aug 2012 04:05:59 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Aug 2012 04:05:10 -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, 27 Aug 2012 07:05:09 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Mon, 27 Aug 2012 07:05:08 -0400 Thread-Topic: Minor Comments on PT-EAP Thread-Index: Ac2EQ9IMC45iMJzjSSC/SkRqm+FlQA== 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] Minor 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, 27 Aug 2012 11:06:00 -0000 I have conducted a detailed review of PT-EAP. I have reviewed the specification many times before but I still found a few minor issues, noted below. I'm surprised that there are still issues, given that this document has been reviewed so many times by so many people (including at least four thorough reviews by me). But I guess there are always a few typos and little errors in every document. Still, there are only a few at this point and the spec overall is quite good. PT-EAP is a valuable specification of high quality. I support sending it to the IESG and on to RFC status. But I'd like to see these minor issues fixed first. Thanks, Steve ----------- Minor Comments on draft-ietf-nea-pt-tls-03.txt * The front page says that the Intended Status is Informational. That should be Standards Track. * Four places in the spec, the phrase "EAP TLS-based tunnel" or "EAP TLS-based tunnel method" appears. This could be misread as a reference to the EAP-TLS method. I think it would be much clearer to change these phrases to "TLS-based EAP tunnel" or "TLS-based EAP tunnel method". * The paragraph immediately before section 1.1 says PT-EAP is designed to be used "under a protected tunnel" such as TEAP, EAP-FAST, or EAP-TTLS. In this phrase, I think the word "under" can be interpreted two ways. Clearly, the authors mean that PT-EAP is used inside a protected tunnel. But the phrase could also mean that PT-EAP is used as a substrate under a protected tunnel. In other words, that the protected tunnel would be encapsulated inside PT-EAP. Clearly, that's nonsense. But this phrase would be much clearer if we replaced the word "under" with "inside". Then it would say PT-EAP is designed to be used "inside a protected tunnel" such as TEAP, EAP-FAST, or EAP-TTLS. * The second paragraph in section 3 says that this section includes "a flow diagram". Actually, there's no flow diagram in that section or anywhere else in the document. I suggest that we remove the words "and a flow diagram" from that paragraph. * The last sentence in that paragraph is missing a word when it says that tls-unique "may be used to PA-TNC exchanges to the EAP tunnel method". I think the word "bind" needs to be added before "PA-TNC" in that sentence. * The words "an PT-EAP" appear in the document three times. Of course, they should be "a PT-EAP". * At the start of section 3.3, the numbers in the message diagram should be one space to the right. They need to line up with the hyphens below, not the plus signs. * At the end of section 3.4, the word "an" should be inserted before the final word "attacker". * The first paragraph of section 4 ends with two periods. One should be enough. Also, the penultimate sentence in that paragraph includes the phrase "do not evaluate". This should be "does not evaluate" to match the singular noun ("this section"). * In sections 4.1.1 and 4.1.2, several bullets start with "Not to". The word "to" should be deleted from those bullets. Otherwise, the bullets are ungrammatical when combined with the text that introduces the bullets. For example, the first bullet when combined with the text before the bullets now reads "The Posture Transport Client is trusted by the Posture Broker Client to [...] Not to observe, fabricate or alter the contents of the PB-TNC batches received from the network". Clearly, the words "Not to" should be simply "Not". * Two bullets in sections 4.1.1 and 4.1.2 start with the words "Deliver properly security protected messages", which are hard to parse. Does this mean "Properly deliver security-protected messages" or "Ensure that messages delivered were properly protected from a security perspective"? Both meanings are sensible and arguably desirable but I think that the first meaning is already covered by the bullet that reads "Not to observe, fabricate or alter the contents of the PB-TNC batches received from the network". While it's clever to include both meanings in this text, I think we're seeking clarity in our text not clever double meanings that might easily be missed by non-native speakers so I suggest rewording these bullets to say "Ensure that PB-TNC batches delivered to and from the network are properly protected from a security perspective while on the network". =20 * In the first full bullet on page 10, I believe that "Posture Transport Client" should be "Posture Broker Client". Otherwise, the bullet makes no sense. Why would the Posture Transport Client need to expose the identity of the Posture Transport Server to the Posture Transport Client (PTC)? We'd have the PTC exposing something to itself. A similar comment applies in section 4.1.2 but in that case "Posture Transport Server" should be "Posture Broker Server". * With respect to the last five bullets in section 4.1.1, I don't think it's safe for the Posture Transport Server to completely trust the Posture Transport Client in these ways. After all, the Posture Transport Client is on an untrusted device. I suggest adding a sentence at the end of section 4.1.1 saying "While the Posture Transport Server expects the Posture Transport Client to follow these expectations, the Posture Transport Server cannot truly trust the Posture Transport Client since it's running on a potentially untrustworthy machine. Therefore, the Posture Transport Server must assume that the Posture Transport Client may be infected and malicious. The Posture Transport Server should protect itself accordingly." A similar argument can be applied to section 4.1.2 but it is not as strong there because the Posture Transport Server is trusted by the Posture Transport Client to some degree since the NEA Server has been authenticated and a decision has been made that it is trusted to receive confidential information about endpoint posture and perhaps to send remediation instructions. Still, I suggest adding the following text at the end of section 4.1.2: While the Posture Transport Client expects the Posture Transport Server to follow these expectations and has inherently placed some trust in the Posture Transport Server by sending information about endpoint security posture to that server, the Posture Transport Client should still protect itself against compromise of the Posture Transport Server or errors in implementation by detecting and protecting against malformed messages and other suspicious behavior on the part of the Posture Transport Server. * In section 4.1.2, the first bullet in the second bulleted list should end in "Posture Transport Client" not "Posture Transport Server". * Section 4.2.2 refers to "fake PT-EAP error codes". There are no PT-EAP error codes. I suggest that we say "malformed PT-EAP messages" instead. * In the first paragraph of section 4.2.4, "the PT-EAP" should be just "PT-EAP". Later in that sentence, the word "are" should be "is" to match the subject of the sentence, "the message exchange". * In section 4.2.5, please add a citation of the NEA Asokan Attack Analysis draft after it is mentioned. That is, add "[I-D.ietf-nea-asokan]". Also, please update the reference in the references section to point to the WG draft version of this document not the individual submission version. And in the first sentence of section 4.2.5, remove the extra period after "3.4". * In the first sentence on top of page 14, change "only known" to "best known". There are other ways to protect against Asokan attacks. For example, one could use behavior analysis to detect an infected machine after it connects to the network. Still, the EMA is by far the best and most effective approach. * The second paragraph of section 4.3 cites EAP-FAST and EAP-TTLS. Please add TEAP.=20 * The third paragraph of section 4.3 cites EAP-TTLS, mentioning that non-EAP authentication is supported. Please change "TTLS" to "EAP-TTLS". Also, please mention TEAP here also since TEAP supports password authentication without using an inner EAP method. * Section 4.3 says "Within each EAP tunnel method will exist a set of inner EAP method [...]". This should be "inner EAP methods" not "inner EAP method". Later in that paragraph, "the outer methods keys" should be "the outer method's keys". * Section 5 refers to the "IETF EAP Method Unification (EMU) working group". The word "Unification" should be "Update" there. Later in that sentence, "the EAP tunnel method" should be "a Standards Track EAP tunnel method". We already have two EAP tunnel methods that are Informational RFCs and satisfy NEA's requirements: EAP-FAST and EAP-TTLS. What's missing is a Standards Track EAP tunnel method. * The first paragraph of section 7 includes a reference to RFC 2434. That RFC has been obsoleted by RFC 5226. We should refer to the newer RFC instead. Also, we should add a period at the end of that paragraph. * Many of the references are not used anywhere in the document. Let's delete them. They are [IEEE], [I-D.ietf-emu-eaptunnel-req], [RFC3478], [RFC5216], [RFC5996], and [TNC-Binding]. Also, [RFC2434] will be unused if you adopt my last suggested change. From sethomso@cisco.com Fri Aug 31 13:30:42 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 81D6A11E80E6 for ; Fri, 31 Aug 2012 13:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qss7mkGKJZ-1 for ; Fri, 31 Aug 2012 13:30:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9837A11E80DC for ; Fri, 31 Aug 2012 13:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4292; q=dns/txt; s=iport; t=1346445041; x=1347654641; h=from:to:subject:date:message-id:mime-version; bh=xK1ziGdpHlpSpMAlhuXzrtGi7CEWmUM/S3UN6CpJRtU=; b=kPFSzu6pi7zowwFy9bcjxXigEjNIkAkXVxlRcJiK2sygEJOl5rjqtBIn WALkAo3aG901/f3ITA7eQkEtU1dAgTEtA35sytBn+dzuG54d5pkZdfgE4 4srUSmF/NuA9Embpw+30ZdsRJTRQ05jIyeR216DELsMdb7EN/GA5bgD1q A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMIdQVCtJXG+/2dsb2JhbABFgkq4VIEHgicSAXgBDHQnBBwZh2sLmR+BKKASkgoDlViOM4FngmM X-IronPort-AV: E=Sophos;i="4.80,349,1344211200"; d="scan'208,217";a="114290868" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 31 Aug 2012 20:30:41 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7VKUe3Q026155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Aug 2012 20:30:40 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.230]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Fri, 31 Aug 2012 15:30:40 -0500 From: "Susan Thomson (sethomso)" To: "nea@ietf.org" Thread-Topic: PT-EAP editorial comments Thread-Index: AQHNh7d8fvDD40vtqk6QX0rBbt1ZcA== Date: Fri, 31 Aug 2012 20:30:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 x-originating-ip: [10.116.64.106] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19154.001 x-tm-as-result: No--30.230100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC6539432DA98sethomsociscocom_" MIME-Version: 1.0 Subject: [Nea] PT-EAP editorial comments 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, 31 Aug 2012 20:30:42 -0000 --_000_CC6539432DA98sethomsociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When reviewing the document, I came across many of the same issues raised b= y Steve , so have not repeated them here. I have some suggestions re clarifying the IANA Considerations to ensure we = comply with guidelines in RFC5226. I think we need to address all comments before sending the document to the= IESG. Otherwise, looks in good shape. Thanks Susan ----------------------------------------- Section 3.3 Type field: Correct name is "EAP method Type" not "EAP Type Method". Also include refer= ence to EAP RFC in description , such as EAP method Type [RFC3478] for PT-EAP Section 7 IANA Considerations: Per IANA Guidelines in RFC5226, I would suggest adding the following: For EAP method Type, include a table with Value, Description and Reference: Value=3DTBD, Description =3D EAP Method Type for PT-EAP, Reference =3D RFC= 3748 Also, add the following sentence containing URL where IANA registry is mai= ntained: [TO BE REMOVED: This registration should take place at the following locati= on: http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3] Section 7.1 EAP Version Registry For the PT-EAP Version Registry, add the value 0 as Reserved in first row o= f table. Section 4.3 End of first sentence. Remove duplicate word "section". --_000_CC6539432DA98sethomsociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <90E62D7CAA309248A4D5E5960E17D0E8@cisco.com> Content-Transfer-Encoding: quoted-printable
When reviewing the document, I came across many of the same issue= s raised by Steve , so have not repeated them here. 

I have some suggestions re clarifying the IANA Considerations to ensur= e we comply with guidelines in RFC5226.

I think we need to address all comments before sending the document &n= bsp;to the  IESG. Otherwise, looks in good shape.

Thanks
Susan
-----------------------------------------

Section 3.3 Type field: 
Correct name is "EAP method Type" not "EAP Type Method&= quot;. Also include reference to EAP RFC in description , such as 
EAP method Type [RFC3478] for PT-EAP

Section 7 IANA Considerations:
Per IANA Guidelines in RFC5226, I would suggest adding the following:<= /div>

For EAP method Type, include a table with Value, Description and Refer= ence:
Value=3DTBD, Description =3D EAP Method Type for PT-EAP,  Referen= ce =3D RFC3748

Also, add the following sentence containing  URL where IANA regis= try is maintained:
[TO BE REMOVED: =
This registration should take place at the following location:

Section 7.1 EAP Version Registry
For the PT-EAP Version Registry, add the value 0 as Reserved in first = row of table.

Section 4.3 End of first sentence.
Remove duplicate word "section".


--_000_CC6539432DA98sethomsociscocom_--