From shanna@juniper.net Thu Nov 1 06:17:20 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 202F221F878C for ; Thu, 1 Nov 2012 06:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, 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 XMXKvD01RnPS for ; Thu, 1 Nov 2012 06:17:18 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFAB21F86F3 for ; Thu, 1 Nov 2012 06:17:18 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKUJJ2XQobi9zA5ch2Br+OJ8Xn9nOUIUq7@postini.com; Thu, 01 Nov 2012 06:17:18 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 1 Nov 2012 06:14:20 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Thu, 1 Nov 2012 06:14:20 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 1 Nov 2012 06:16:10 -0700 Received: from mail129-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE007.bigfish.com (10.243.66.70) with Microsoft SMTP Server id 14.1.225.23; Thu, 1 Nov 2012 13:14:19 +0000 Received: from mail129-co1 (localhost [127.0.0.1]) by mail129-co1-R.bigfish.com (Postfix) with ESMTP id B24BE740125 for ; Thu, 1 Nov 2012 13:14:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -28 X-BigFish: PS-28(zz9371Id6eahfecI542Mef7I4015Izz1202h1d1ah1d2ahz31iz1033IL8275dhz2dh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received: from mail129-co1 (localhost.localdomain [127.0.0.1]) by mail129-co1 (MessageSwitch) id 1351775658797106_7673; Thu, 1 Nov 2012 13:14:18 +0000 (UTC) Received: from CO1EHSMHS015.bigfish.com (unknown [10.243.78.247]) by mail129-co1.bigfish.com (Postfix) with ESMTP id C09647C0050 for ; Thu, 1 Nov 2012 13:14:18 +0000 (UTC) Received: from BY2PRD0510HT004.namprd05.prod.outlook.com (157.56.236.101) by CO1EHSMHS015.bigfish.com (10.243.66.25) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 1 Nov 2012 13:14:18 +0000 Received: from BY2PRD0510MB366.namprd05.prod.outlook.com ([169.254.6.143]) by BY2PRD0510HT004.namprd05.prod.outlook.com ([10.255.84.39]) with mapi id 14.16.0233.002; Thu, 1 Nov 2012 13:14:18 +0000 From: Stephen Hanna To: "'nea@ietf.org'" Thread-Topic: Help the NomCom Thread-Index: AQHNuDCZyq3hQHcKI0GgBoDMFIvwj5fU9Hiw Date: Thu, 1 Nov 2012 13:14:16 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: [Nea] FW: Help the NomCom 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, 01 Nov 2012 13:17:20 -0000 UGxlYXNlIGFpZCB0aGUgSUVURiBOb21pbmF0aW5nIENvbW1pdHRlZSBieSBnb2luZyB0bw0KDQpo dHRwczovL3d3dy5pZXRmLm9yZy9ncm91cC9ub21jb20vMjAxMi9pbnB1dA0KDQphbmQgZW50ZXJp bmcgeW91ciBmZWVkYmFjayBvbiBjYW5kaWRhdGVzIGZvciBJRVNHDQphbmQgb3RoZXIgaW1wb3J0 YW50IElFVEYtcmVsYXRlZCBvZmZpY2VzLiBUaGlzDQpzaG91bGQgbm90IHRha2UgbW9yZSB0aGFu IHR3byBvciB0aHJlZSBtaW51dGVzIGZvcg0KbW9zdCBvZiB5b3UgYW5kIGl0IHdpbGwgc3Vic3Rh bnRpYWxseSBpbXByb3ZlIHRoZQ0KcXVhbGl0eSBvZiB0aGUgTm9taW5hdGluZyBDb21taXR0ZWUn cyBkZWNpc2lvbnMuDQoNCklmIHlvdSBkb24ndCBrbm93IHNvbWUgb2YgdGhlIGNhbmRpZGF0ZXMs IHlvdQ0KbmVlZG4ndCBib3RoZXIgdG8gY29tbWVudCBvbiB0aGVtLiBUaGF0IHNob3VsZA0KbWFr ZSB5b3VyIGNvbW1lbnRpbmcgam9iIHByZXR0eSBxdWljayENCg0KVGhhbmtzLA0KDQpTdGV2ZQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogd2djaGFpcnMtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOndnY2hhaXJzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOb21D b20gQ2hhaXINClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwMSwgMjAxMiA4OjE3IEFNDQpUbzog V29ya2luZyBHcm91cCBDaGFpcnMNClN1YmplY3Q6IENPUlJFQ1RJT046IEhlbHAgdGhlIE5vbUNv bQ0KDQpJIHNlbnQgYSBtZXNzYWdlIHNldmVyYWwgaG91cnMgYWdvIHJlcXVlc3RpbmcgdGhhdCB5 b3UgaGVscCBhbmQgbWFrZSANCnlvdXIgd29ya2luZyBncm91cCBhd2FyZSB0aGF0IHRoZSBOb21D b20gaXMgbG9va2luZyBmb3IgaW5wdXQgZnJvbSB0aGUgDQpjb21tdW5pdHkuIFRoaXMgbWVzc2Fn ZSBoYWQgYSBtaW5vciBlcnJvci4gVGhlIE5vbUNvbSBuZWVkcyB0byANCnJlY2VpdmUgY29tbXVu aXR5IGlucHV0IGJ5IE5vdmVtYmVyIDExLCAyMDEyLiANCg0KVGhlIGZ1bGwgdGV4dCBvZiB0aGUg Y29ycmVjdGVkIG1lc3NhZ2UgaXMgYmVsb3cNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpUaGUgSUVURiBOb21pbmF0aW9ucyBDb21taXR0ZWUg KE5vbUNvbSkgY29udGludWVzIHRvIHNlZWsgaW5wdXQgZnJvbQ0KdGhlIElFVEYgQ29tbXVuaXR5 LiBUaGUgTm9tQ29tIHdvdWxkIGdyZWF0bHkgYXBwcmVjaWF0ZSBhbnkgaGVscCB5b3UNCmNvdWxk IHByb3ZpZGUgaW4gbWFraW5nIG1lbWJlcnMgb2YgeW91ciB3b3JraW5nIGdyb3VwIGF3YXJlIG9m IHdheXMgaW4NCndoaWNoIHRoZXkgY2FuIHByb3ZpZGUgdmFsdWFibGUgZmVlZGJhY2sgdG8gdGhl IE5vbUNvbS4NCg0KSW4gb3JkZXIgdG8gZW5zdXJlIHRoYXQgeW91ciBpbnB1dCBpcyByZWNlaXZl ZCBpbiB0aW1lIHRvIGJlIHVzZWZ1bCwgdGhlIA0KTm9tQ29tIG5lZWRzIHRvIHJlY2VpdmUgY29t bXVuaXR5IGZlZWRiYWNrIG9uIG9yIGJlZm9yZSBTdW5kYXksIE5vdmVtYmVyIDExLg0KDQpUaGUg ZmluYWwgbGlzdCBvZiBjYW5kaWRhdGVzIChhcyBwZXIgUkZDIDU2ODApIHRoYXQgdGhlIE5vbUNv bSBpcyANCmNvbnNpZGVyaW5nIGZvciBvcGVuIHBvc2l0aW9ucyBjYW4gYmUgZm91bmQgYXQ6IA0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvZ3JvdXAvbm9tY29tLzIwMTIvaW5wdXQvDQoNClRoZSBOb21D b20gd2lsbCBiZSBob2xkaW5nIG9mZmljZSBob3VycyBkdXJpbmcgSUVURiA4NSwgTW9uZGF5LQ0K VGh1cnNkYXkgZnJvbSAxOjAwcG0gdG8gMzowMHBtIGluIFJvb20gMzA1LiBUaGUgTm9tQ29tIHdl bGNvbWVzIA0KY29tbWVudHMgb24gc3BlY2lmaWMgaW5kaXZpZHVhbHMsIGFzIHdlbGwgYXMgZ2Vu ZXJhbCBmZWVkYmFjayByZWxhdGVkIHRvIA0KYW55IG9mIHRoZSBwb3NpdGlvbnMgdGhhdCBOb21D b20gaXMgY29uc2lkZXJpbmcuDQoNCk5vdGU6IEEgbGlzdCBvZiBsZWFkZXJzaGlwIHBvc2l0aW9u cyB0aGF0IHRoZSBOb21Db20gaXMgY29uc2lkZXJpbmcgY2FuIGJlIA0KZm91bmQgYXQ6IGh0dHBz Oi8vd3d3LmlldGYub3JnL2dyb3VwL25vbWNvbS8yMDEyLw0KDQpJZiB0aGUgTm9tQ29tIG9mZmlj ZSBob3VycyBhcmUgaW5jb252ZW5pZW50IGZvciB5b3Ugb3IgaWYgeW91IGNhbm5vdCANCmF0dGVu ZCBJRVRGIDg1LCB0aGUgTm9tQ29tIGlzIGhhcHB5IHRvIHRha2UgY29tbXVuaXR5IGlucHV0IHZp YSBlbWFpbCANCnRvIG5vbWNvbTEyIGF0IGlldGYub3JnLiBBZGRpdGlvbmFsbHksIHRoZSBOb21D b20gaXMgaGFwcHkgdG8gYXJyYW5nZSBhIA0KbWVldGluZyBvdXRzaWRlIG9mIG9mZmljZSBob3Vy cywganVzdCBzZW5kIHVzIGVtYWlsIGFuZCB3ZSBjYW4gc2V0IA0Kc29tZXRoaW5nIHVwLg0KDQpD b21tZW50cyBvbiBzcGVjaWZpYyBjYW5kaWRhdGVzIGNhbiBhbHNvIGJlIHByb3ZpZGVkIHRvIHRo ZSBOb21Db20NCnZpYSB0aGUgd2ViIGZlZWRiYWNrIHRvb2w6IA0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvZ3JvdXAvbm9tY29tLzIwMTIvaW5wdXQvDQoNClRoYW5rIHlvdSBmb3IgeW91ciBoZWxwLA0K LSBNYXR0IExlcGluc2tpDQogIG5vbWNvbS1jaGFpciBhdCBpZXRmLm9yZw0KDQo= From stephen.farrell@cs.tcd.ie Mon Nov 5 14:40: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 3EB6021F876B for ; Mon, 5 Nov 2012 14:40:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyfR8VNgOgTa for ; Mon, 5 Nov 2012 14:40:47 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 957DE21F8516 for ; Mon, 5 Nov 2012 14:40:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4D3F6BE32 for ; Mon, 5 Nov 2012 22:40:25 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHn2togEIx97 for ; Mon, 5 Nov 2012 22:40:24 +0000 (GMT) Received: from [130.129.96.58] (dhcp-603a.meeting.ietf.org [130.129.96.58]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 68769BE27 for ; Mon, 5 Nov 2012 22:40:24 +0000 (GMT) Message-ID: <50984057.2000605@cs.tcd.ie> Date: Mon, 05 Nov 2012 22:40:23 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "nea@ietf.org" X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Nea] pt-tls IPR situation 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, 05 Nov 2012 22:40:48 -0000 Hiya, So I've been chatting with folks about the late IPR declaration and here's what I've found out/concluded about it: - the patent application was initially filed in 2004 - it pre-dates current "publish after 18 months USPTO scheme" (or that doesn't apply) so application is not now public - application won't be published in next few days - the IETF will need to decide what we think based on current information - the process of doing the shepherd write-up for pt-eap brought the application to Susan's attention - internal Cisco discussion then resulted in the declarations being made once that discussion concluded that the application was relevant (that part happened within days/weeks as it ought) - this does represent an oversight on the part of Cisco and the inventors - they should have, but didn't, declare this earlier - the inventors are very sorry and have apologised - based on a phone conversation with the inventors, as AD I'm happy that the above is the case, i.e. its a genuine error that was corrected once it was belatedly discovered - As AD, I'll shortly issue a 2nd IETF LC for the PT-TLS document and we'll process it as usual, if you find that problematic, please comment during that IETF LC. Regards, Stephen. From tglassey@earthlink.net Mon Nov 5 15:01:02 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 B2D1C11E80A5 for ; Mon, 5 Nov 2012 15:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, 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 JoHCYBSJov+4 for ; Mon, 5 Nov 2012 15:01:02 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 2121711E8097 for ; Mon, 5 Nov 2012 15:01:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=OUR3jp8a2gmOBlUNNVUDiLu3D29wnE7z8ChGP1V/H0tnVyu5aSbpme3VL3svQF66; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [67.180.133.21] (helo=[192.168.15.2]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1TVVfB-0004wS-6G for nea@ietf.org; Mon, 05 Nov 2012 18:01:01 -0500 Message-ID: <5098452F.5020501@earthlink.net> Date: Mon, 05 Nov 2012 15:01:03 -0800 From: tglassey User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: nea@ietf.org References: <50984057.2000605@cs.tcd.ie> In-Reply-To: <50984057.2000605@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7910021f76d8496bfa59b158060763b7cf350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.180.133.21 Subject: Re: [Nea] pt-tls IPR situation 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, 05 Nov 2012 23:01:02 -0000 On 11/5/2012 2:40 PM, Stephen Farrell wrote: > Hiya, > > So I've been chatting with folks about the late IPR > declaration and here's what I've found out/concluded > about it: > > - the patent application was initially filed in > 2004 > - it pre-dates current "publish after 18 months USPTO > scheme" (or that doesn't apply) so application is > not now public > - application won't be published in next few days > - the IETF will need to decide what we think based > on current information > - the process of doing the shepherd write-up for > pt-eap brought the application to Susan's > attention > - internal Cisco discussion then resulted in the > declarations being made once that discussion > concluded that the application was relevant (that > part happened within days/weeks as it ought) > - this does represent an oversight on the part of > Cisco and the inventors - they should have, but > didn't, declare this earlier > - the inventors are very sorry and have apologised > - based on a phone conversation with the inventors, > as AD I'm happy that the above is the case, i.e. > its a genuine error that was corrected once it > was belatedly discovered > - As AD, I'll shortly issue a 2nd IETF LC for the > PT-TLS document and we'll process it as usual, > if you find that problematic, please comment > during that IETF LC. > > Regards, > Stephen. Has anyone gotten a formal explanation from Cisco's legal department - it makes a difference. Todd > > > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > -- Regards TSG "Ex-Cruce-Leo" //Confidential Mailing - Please destroy this if you are not the intended recipient. From stephen.farrell@cs.tcd.ie Mon Nov 5 15:03:15 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 8250C21F889F for ; Mon, 5 Nov 2012 15:03:15 -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=[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 VaxMZ7bUd883 for ; Mon, 5 Nov 2012 15:03:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7A521F8441 for ; Mon, 5 Nov 2012 15:03:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AF437BE32; Mon, 5 Nov 2012 23:02:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccRTdW+qPXpQ; Mon, 5 Nov 2012 23:02:48 +0000 (GMT) Received: from [130.129.96.58] (dhcp-603a.meeting.ietf.org [130.129.96.58]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CE0A9BE27; Mon, 5 Nov 2012 23:02:47 +0000 (GMT) Message-ID: <50984596.8010702@cs.tcd.ie> Date: Mon, 05 Nov 2012 23:02:46 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: tglassey References: <50984057.2000605@cs.tcd.ie> <5098452F.5020501@earthlink.net> In-Reply-To: <5098452F.5020501@earthlink.net> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: nea@ietf.org Subject: Re: [Nea] pt-tls IPR situation 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, 05 Nov 2012 23:03:15 -0000 On 11/05/2012 11:01 PM, tglassey wrote: >> > Has anyone gotten a formal explanation from Cisco's legal department - > it makes a difference. I did not. S. From iesg-secretary@ietf.org Mon Nov 5 15:12: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 A4C6721F867A; Mon, 5 Nov 2012 15:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 yfSQv4jyNXKm; Mon, 5 Nov 2012 15:12:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39F0821F8552; Mon, 5 Nov 2012 15:12:22 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121105231222.30829.36274.idtracker@ietfa.amsl.com> Date: Mon, 05 Nov 2012 15:12:22 -0800 Cc: nea@ietf.org Subject: [Nea] Last Call: (PT-TLS: A TLS-based Posture Transport (PT) Protocol) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 23:12:22 -0000 The IESG has received a request from the Network Endpoint Assessment WG (nea) to consider the following document: - 'PT-TLS: A TLS-based Posture Transport (PT) Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-11-19. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This second last call is caused by a late IPR declaration on the document. (See the link below.) Abstract This document specifies PT-TLS, a TLS-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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1890/ From adam@stoicsecurity.com Mon Nov 5 15:18:36 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 C88AC21F84D5 for ; Mon, 5 Nov 2012 15:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDG0OgABZsWs for ; Mon, 5 Nov 2012 15:18:36 -0800 (PST) Received: from m1plsmtpa01-02.prod.mesa1.secureserver.net (m1plsmtpa01-02.prod.mesa1.secureserver.net [64.202.165.174]) by ietfa.amsl.com (Postfix) with ESMTP id E616721F84BF for ; Mon, 5 Nov 2012 15:18:35 -0800 (PST) Received: from [130.129.20.206] ([130.129.20.206]) by m1plsmtpa01-02.prod.mesa1.secureserver.net with id KzJZ1k00K4Smisq01zJaxg; Mon, 05 Nov 2012 16:18:34 -0700 References: <50984057.2000605@cs.tcd.ie> <5098452F.5020501@earthlink.net> <50984596.8010702@cs.tcd.ie> Mime-Version: 1.0 (1.0) In-Reply-To: <50984596.8010702@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <75AC78B0-4F5F-439A-9F63-7E636B5C297F@stoicsecurity.com> X-Mailer: iPhone Mail (10A523) From: "Adam W. Montville" Date: Mon, 5 Nov 2012 18:18:32 -0500 To: Stephen Farrell Cc: "nea@ietf.org" Subject: Re: [Nea] pt-tls IPR situation 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, 05 Nov 2012 23:18:37 -0000 On Nov 5, 2012, at 6:02 PM, Stephen Farrell wrot= e: >=20 >=20 > On 11/05/2012 11:01 PM, tglassey wrote: >> Has anyone gotten a formal explanation from Cisco's legal department - >> it makes a difference. >=20 > I did not. As a newcomer/outsider what insight would a formal legal explanation provide= ? >=20 > S. >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From internet-drafts@ietf.org Tue Nov 6 10:57:43 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 346F421F8A56; Tue, 6 Nov 2012 10:57:43 -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=[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 loXDZcVdmo1d; Tue, 6 Nov 2012 10:57:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58F021F8963; Tue, 6 Nov 2012 10:57:42 -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.35 Message-ID: <20121106185742.7283.55433.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 10:57:42 -0800 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-eap-04.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, 06 Nov 2012 18:57:43 -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-EAP: Posture Transport (PT) Protocol For EAP Tunnel M= ethods Author(s) : Nancy Cam-Winget Paul Sangster Filename : draft-ietf-nea-pt-eap-04.txt Pages : 21 Date : 2012-11-06 Abstract: This document specifies PT-EAP, an EAP based Posture Transport (PT) protocol designed to be used only inside a TLS protected tunnel method. The document also describes the intended applicability of PT-EAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-nea-pt-eap-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-nea-pt-eap-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Nov 12 20:41:41 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 8A75621F88A4; Mon, 12 Nov 2012 20:41:41 -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=[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 mBRh+Nr9Y51x; Mon, 12 Nov 2012 20:41:40 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B2F21F87DF; Mon, 12 Nov 2012 20:41:40 -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.36 Message-ID: <20121113044140.2047.22370.idtracker@ietfa.amsl.com> Date: Mon, 12 Nov 2012 20:41:40 -0800 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-eap-05.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, 13 Nov 2012 04:41:41 -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-EAP: Posture Transport (PT) Protocol For EAP Tunnel M= ethods Author(s) : Nancy Cam-Winget Paul Sangster Filename : draft-ietf-nea-pt-eap-05.txt Pages : 20 Date : 2012-11-12 Abstract: This document specifies PT-EAP, an EAP based Posture Transport (PT) protocol designed to be used only inside a TLS protected tunnel method. The document also describes the intended applicability of PT-EAP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-nea-pt-eap-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-nea-pt-eap-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sethomso@cisco.com Wed Nov 14 17:57:46 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 0FDFC21E802E; Wed, 14 Nov 2012 17:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.098 X-Spam-Level: X-Spam-Status: No, score=-110.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, 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 XBFExgEBQlvM; Wed, 14 Nov 2012 17:57:44 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 92F7821F84DF; Wed, 14 Nov 2012 17:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12857; q=dns/txt; s=iport; t=1352944664; x=1354154264; h=from:to:cc:subject:date:message-id:mime-version; bh=TENvFuB2QSLQYBQFXzAP/vzhw/ZmvCTTaeWHeaIgZ3g=; b=fnaIS9kTw9Ub/2Lcr8+2icqI4eSCHu2ZjeaMApIuv5P8iq7Lqxa+k5c3 skKDzG+Sk3pQLF0w5MHCigAyUkGkcwztfilm8Es4DW3p5JwvokPB3CL/5 CGFs/fHisaB8Dj/CiNQejh4uTTXkvn1LAJ5PXVjDf81t/6juxQ/gGvzPG E=; X-Files: pt-eap-doc-shepherd-v1.txt : 7934 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ1LpFCtJXHB/2dsb2JhbAA6CoJJwHyBCIIVCwEEEgEKTgMEBxIBCwEeJjAnBAENDQEFFIdpC5tJoAaMPQqFMWEDjnuVWYFrgm+BXQcXBhg X-IronPort-AV: E=McAfee;i="5400,1158,6896"; a="142568456" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 15 Nov 2012 01:57:44 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qAF1vhXE006461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Nov 2012 01:57:44 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.76]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 19:57:43 -0600 From: "Susan Thomson (sethomso)" To: Stephen Farrell , IESG Secretary Thread-Topic: PT-EAP I-D Ready for IESG Evaluation Thread-Index: AQHNwtSZN/2pZMSZSky8DUtOu+QtBQ== Date: Thu, 15 Nov 2012 01:57:42 +0000 Message-ID: <28EBD44EA702D74DB2B6AABD0511BBEF1FE022@xmb-rcd-x06.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes 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-19364.000 x-tm-as-result: No--28.442000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/mixed; boundary="_004_28EBD44EA702D74DB2B6AABD0511BBEF1FE022xmbrcdx06ciscocom_" MIME-Version: 1.0 Cc: "nea@ietf.org" Subject: [Nea] PT-EAP I-D Ready for IESG Evaluation 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, 15 Nov 2012 01:57:46 -0000 --_004_28EBD44EA702D74DB2B6AABD0511BBEF1FE022xmbrcdx06ciscocom_ Content-Type: multipart/alternative; boundary="_000_28EBD44EA702D74DB2B6AABD0511BBEF1FE022xmbrcdx06ciscocom_" --_000_28EBD44EA702D74DB2B6AABD0511BBEF1FE022xmbrcdx06ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen The PT-EAP I-D (draft-ietf-nea-pt-eap-05.txt) has completed WG Last Call an= d is ready for IESG evaluation as Proposed Standard. I am document shepherd and the write-up is attached. Thanks Susan --_000_28EBD44EA702D74DB2B6AABD0511BBEF1FE022xmbrcdx06ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <31D8ED3C62963441A74B74DBEE91328D@cisco.com> Content-Transfer-Encoding: quoted-printable
Stephen

The PT-EAP I-D (draft-ietf-nea-pt-eap-05.txt) has completed WG Last Ca= ll and is ready for IESG evaluation as Proposed Standard.

I am document shepherd and the write-up is attached.

Thanks
Susan
--_000_28EBD44EA702D74DB2B6AABD0511BBEF1FE022xmbrcdx06ciscocom_-- --_004_28EBD44EA702D74DB2B6AABD0511BBEF1FE022xmbrcdx06ciscocom_ Content-Type: text/plain; name="pt-eap-doc-shepherd-v1.txt" Content-Description: pt-eap-doc-shepherd-v1.txt Content-Disposition: attachment; filename="pt-eap-doc-shepherd-v1.txt"; size=7934; creation-date="Thu, 15 Nov 2012 01:57:42 GMT"; modification-date="Thu, 15 Nov 2012 01:57:42 GMT" Content-ID: <86D08EC76922A247A57E7DDD8EFC4106@cisco.com> Content-Transfer-Encoding: base64 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLCBJbnRlcm5ldCANU3RhbmRhcmQsIEluZm9ybWF0aW9uYWwsIEV4cGVyaW1lbnRhbCwg b3IgSGlzdG9yaWMpPyBXaHkgaXMgdGhpcyB0aGUgcHJvcGVyIHR5cGUgDW9mIFJGQz8gSXMgdGhp cyB0eXBlIG9mIFJGQyBpbmRpY2F0ZWQgaW4gdGhlIHRpdGxlIHBhZ2UgaGVhZGVyPwoNUHJvcG9z ZWQgU3RhbmRhcmQgaXMgcmVxdWVzdGVkIGFuZCBpbmRpY2F0ZWQgaW4gdGhlIGhlYWRlci4KDVBU LUVBUCBkZWZpbmVzIGEgdHJhbnNwb3J0IHByb3RvY29sIHRvIGNhcnJ5IE5FQSBwb3N0dXJlIG1l c3NhZ2VzIGJldHdlZW4gYSANTkVBIGNsaWVudCBhbmQgc2VydmVyIGFzIHBhcnQgb2YgbmV0d29y ayBhY2Nlc3MuIFByb3Bvc2VkIHN0YW5kYXJkIGlzIHJlcXVlc3RlZCANYmVjYXVzZSBhIHRyYW5z cG9ydCBwcm90b2NvbCBpcyBuZWVkZWQgZm9yIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBORUEg Y2xpZW50IA1hbmQgc2VydmVycyBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzLgoNKDIpIFRoZSBJRVNH IGFwcHJvdmFsIGFubm91bmNlbWVudCBpbmNsdWRlcyBhIERvY3VtZW50IEFubm91bmNlbWVudCBX cml0ZS0NVXAuIFBsZWFzZSBwcm92aWRlIHN1Y2ggYSBEb2N1bWVudCBBbm5vdW5jZW1lbnQgV3Jp dGUtVXAuIFJlY2VudCBleGFtcGxlcyANY2FuIGJlIGZvdW5kIGluIHRoZSAiQWN0aW9uIiBhbm5v dW5jZW1lbnRzIGZvciBhcHByb3ZlZCBkb2N1bWVudHMuIFRoZSANYXBwcm92YWwgYW5ub3VuY2Vt ZW50IGNvbnRhaW5zIHRoZSBmb2xsb3dpbmcgc2VjdGlvbnM6Cg1UZWNobmljYWwgU3VtbWFyeToN ICAgICAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgUFQtRUFQLCBhbiBFQVAtYmFzZWQgUG9zdHVy ZSBUcmFuc3BvcnQgKFBUKQogICAgICBwcm90b2NvbCBkZXNpZ25lZCB0byBiZSB1c2VkIGluc2lk ZSBhIFRMUy1wcm90ZWN0ZWQgdHVubmVsDSAgICAgIG1ldGhvZC4gIFRoZSBkb2N1bWVudCBhbHNv IGRlc2NyaWJlcyB0aGUgaW50ZW5kZWQgYXBwbGljYWJpbGl0eSBvZg0gICAgICBQVC1FQVAuDQ1X b3JraW5nIEdyb3VwIFN1bW1hcnk6DQoKSW4gdGhlIGNhbGwgZm9yIHByb3Bvc2FscyBmb3IgUG9z dHVyZSBUcmFuc3BvcnQgKFBUKSBzcGVjaWZpY2F0aW9ucywgdGhlcmUgDXdlcmUgdHdvIHN1Ym1p c3Npb25zIGZvciBhbiBFQVAtYmFzZWQgUFQ6IG9uZSB1c2luZyBhbiBFQVAgbWV0aG9kIA13aXRo aW4gYW4gRUFQIHR1bm5lbCBtZXRob2QsIGFuZCB0aGUgb3RoZXIgdXNpbmcgYSBUTFYgZm9ybWF0 IHdpdGhpbiBhbiANRUFQIHR1bm5lbCBtZXRob2QuIE1hbnkgZGlzY3Vzc2lvbnMgd2VyZSBoYWQg aW4gdGhlIFdHIG9uIHRoZSBwcm9zIGFuZCANY29ucyBvZiBlYWNoIGFwcHJvYWNoLiBObyBjb25z ZW5zdXMgY291bGQgYmUgcmVhY2hlZC4gSGVuY2UsIHRoZSBBRCBvZiANdGhlIFdvcmtpbmcgR3Jv dXAgKFN0ZXBoZW4gRmFycmVsbCkgbWFkZSB0aGUgc2VsZWN0aW9uIHdpdGggdGhlIA1hZ3JlZW1l bnQgdGhhdCB0aGUgV0cgd291bGQgYWJpZGUgYnkgdGhlIGRlY2lzaW9uLiBTdGVwaGVuIHNlbGVj dGVkIHRoZSANRUFQIG1ldGhvZCBhcHByb2FjaCBpbiBhIG1lc3NhZ2UgdG8gdGhlIE5FQSBXRyBk YXRlZCAyNCBBdWcgMjAxMSANKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9u ZWEvY3VycmVudC9tc2cwMTE4Ny5odG1sKS4gVGhlIA1XRyB0aGVuIGFkb3B0ZWQgdGhlIEVBUCBt ZXRob2QgcHJvcG9zYWwgYXMgYSBXRyBkb2N1bWVudCwgYW5kIA1mb2xsb3dlZCB0aGUgbm9ybWFs IHByb2Nlc3MgZnJvbSB0aGVyZS4gVGhlcmUgaXMgV0cgY29uc2Vuc3VzIHRvIG1vdmUgDXRoaXMg ZG9jdW1lbnQgZm9yd2FyZC4NCgpEb2N1bWVudCBRdWFsaXR5Og0KCkFyZSB0aGVyZSBleGlzdGlu ZyBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIHByb3RvY29sPyBIYXZlIGEgc2lnbmlmaWNhbnQgDW51 bWJlciBvZiB2ZW5kb3JzIGluZGljYXRlZCB0aGVpciBwbGFuIHRvIGltcGxlbWVudCB0aGUgc3Bl Y2lmaWNhdGlvbj8gQXJlIA10aGVyZSBhbnkgcmV2aWV3ZXJzIHRoYXQgbWVyaXQgc3BlY2lhbCBt ZW50aW9uIGFzIGhhdmluZyBkb25lIGEgdGhvcm91Z2ggDXJldmlldywgZS5nLiwgb25lIHRoYXQg cmVzdWx0ZWQgaW4gaW1wb3J0YW50IGNoYW5nZXMgb3IgYSBjb25jbHVzaW9uIHRoYXQgDXRoZSBk b2N1bWVudCBoYWQgbm8gc3Vic3RhbnRpdmUgaXNzdWVzPyBJZiB0aGVyZSB3YXMgYSBNSUIgRG9j dG9yLCBNZWRpYSANVHlwZSBvciBvdGhlciBleHBlcnQgcmV2aWV3LCB3aGF0IHdhcyBpdHMgY291 cnNlIChicmllZmx5KT8gSW4gdGhlIGNhc2Ugb2YgYSANTWVkaWEgVHlwZSByZXZpZXcsIG9uIHdo YXQgZGF0ZSB3YXMgdGhlIHJlcXVlc3QgcG9zdGVkPw0KClRoZXJlIGFyZSBubyBrbm93biB2ZW5k b3IgaW1wbGVtZW50YXRpb25zIG9mIHRoaXMgcGFydGljdWxhciBzcGVjaWZpY2F0aW9uLCANYnV0 IHRoZXJlIGFyZSBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgYW4gRUFQIG1ldGhvZCB3aGlj aCBpcyBzaW1pbGFyIHRvIA13aGF0IGlzIGN1cnJlbnRseSBzcGVjaWZpZWQuIFRoaXMgZG9jdW1l bnQgd2FzIHJldmlld2VkIGJ5IHNldmVyYWwgcGVvcGxlIA1pbiB0aGUgRU1VIFdHLCBhbmQgbm8g b2JqZWN0aW9ucyB3ZXJlIHJhaXNlZC4NCgpQZXJzb25uZWw6DQoKV2hvIGlzIHRoZSBEb2N1bWVu dCBTaGVwaGVyZD8gV2hvIGlzIHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yPw0KClN1c2Fu IFRob21zb24gaXMgdGhlIERvY3VtZW50IFNoZXBoZXJkLiBTdGVwaGVuIEZhcnJlbGwgaXMgdGhl IEFyZWEgDURpcmVjdG9yLg0KCigzKSBCcmllZmx5IGRlc2NyaWJlIHRoZSByZXZpZXcgb2YgdGhp cyBkb2N1bWVudCB0aGF0IHdhcyBwZXJmb3JtZWQgYnkgdGhlIA1Eb2N1bWVudCBTaGVwaGVyZC4g SWYgdGhpcyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBpcyBub3QgcmVhZHkgZm9yIHB1YmxpY2F0 aW9uLCANcGxlYXNlIGV4cGxhaW4gd2h5IHRoZSBkb2N1bWVudCBpcyBiZWluZyBmb3J3YXJkZWQg dG8gdGhlIElFU0cuDQoKSSBoYXZlIHJldmlld2VkIHRoZSBkb2N1bWVudCBhbmQgZG8gbm90IGhh dmUgaXNzdWVzIHdpdGggaXQuDQoKKDQpIERvZXMgdGhlIGRvY3VtZW50IFNoZXBoZXJkIGhhdmUg YW55IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvciBicmVhZHRoIA1vZiB0aGUgcmV2aWV3cyB0 aGF0IGhhdmUgYmVlbiBwZXJmb3JtZWQ/DQoKTm8uIA0KCig1KSBEbyBwb3J0aW9ucyBvZiB0aGUg ZG9jdW1lbnQgbmVlZCByZXZpZXcgZnJvbSBhIHBhcnRpY3VsYXIgb3IgZnJvbSBicm9hZGVyIA1w ZXJzcGVjdGl2ZSwgZS5nLiwgc2VjdXJpdHksIG9wZXJhdGlvbmFsIGNvbXBsZXhpdHksIEFBQSwg RE5TLCBESENQLCBYTUwsIG9yIA1pbnRlcm5hdGlvbmFsaXphdGlvbj8gSWYgc28sIGRlc2NyaWJl IHRoZSByZXZpZXcgdGhhdCB0b29rIHBsYWNlLg0KCkFzIG1lbnRpb25lZCBhYm92ZSwgdGhlIGRy YWZ0IHdhcyBjaXJjdWxhdGVkIHRvIHRoZSBFTVUgbWFpbGluZyBsaXN0LiBUaHJlZSANcGVvcGxl IG1hZGUgY29tbWVudHMgd2hpY2ggaGF2ZSBiZWVuIGFkZHJlc3NlZC4gTm8gc2lnbmlmaWNhbnQg b2JqZWN0aW9ucyB0byANdGhlIEktRCB3ZXJlIG1hZGUgYXQgdGhhdCB0aW1lLg0KCig2KSBEZXNj cmliZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IgaXNzdWVzIHRoYXQgdGhlIERvY3VtZW50IFNo ZXBoZXJkIGhhcyANd2l0aCB0aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEg RGlyZWN0b3IgYW5kL29yIHRoZSBJRVNHIHNob3VsZCBiZSANYXdhcmUgb2Y/IEZvciBleGFtcGxl LCBwZXJoYXBzIGhlIG9yIHNoZSBpcyB1bmNvbWZvcnRhYmxlIHdpdGggY2VydGFpbiBwYXJ0cyBv ZiANdGhlIGRvY3VtZW50LCBvciBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFsbHkgaXMg YSBuZWVkIGZvciBpdC4gSW4gYW55IGV2ZW50LCANaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhv c2UgaXNzdWVzIGFuZCBoYXMgaW5kaWNhdGVkIHRoYXQgaXQgc3RpbGwgd2lzaGVzIHRvIA1hZHZh bmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlIGNvbmNlcm5zIGhlcmUuDQoKTm8gY29uY2Vy bnMuDQoKKDcpIEhhcyBlYWNoIGF1dGhvciBjb25maXJtZWQgdGhhdCBhbnkgYW5kIGFsbCBhcHBy b3ByaWF0ZSBJUFIgZGlzY2xvc3VyZXMgDXJlcXVpcmVkIGZvciBmdWxsIGNvbmZvcm1hbmNlIHdp dGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1AgNzkgaGF2ZSANYWxyZWFkeSBiZWVu IGZpbGVkLiBJZiBub3QsIGV4cGxhaW4gd2h5Pw0KClllcy4gDQoKKDgpIEhhcyBhbiBJUFIgZGlz Y2xvc3VyZSBiZWVuIGZpbGVkIHRoYXQgcmVmZXJlbmNlcyB0aGlzIGRvY3VtZW50PyBJZiBzbywg DXN1bW1hcml6ZSBhbnkgV0cgZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiByZWdhcmRpbmcgdGhl IElQUiBkaXNjbG9zdXJlcy4NCgpZZXMgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXBy LzE4ODkvKS4gVGhlIFdHIGhhcyBkaXNjdXNzZWQgd2hldGhlciB0byANbW92ZSBmb3J3YXJkIHdp dGggdGhlIGRvY3VtZW50IGdpdmVuIHRoZSBJUFIgZGlzY2xvc3VyZSwgYW5kIHRoZXJlIGlzIGNv bnNlbnN1cyANdG8gZG8gc28uDQoKKDkpIEhvdyBzb2xpZCBpcyB0aGUgV0cgY29uc2Vuc3VzIGJl aGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0IHJlcHJlc2VudCB0aGUgDXN0cm9uZyBjb25jdXJy ZW5jZSBvZiBhIGZldyBpbmRpdmlkdWFscywgd2l0aCBvdGhlcnMgYmVpbmcgc2lsZW50LCBvciBk b2VzIHRoZSBXRyANYXMgYSB3aG9sZSB1bmRlcnN0YW5kIGFuZCBhZ3JlZSB3aXRoIGl0Pw0KClRo ZSBXRyBoYXMgYSB0aG9yb3VnaCB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjb250ZW50cyBvZiB0aGlz IGRvY3VtZW50IGFuZCB0aGVyZSANaXMgY29uc2Vuc3VzIHRvIG1vdmUgdGhlIGRvY3VtZW50IGZv cndhcmQuDQoKKDEwKSBIYXMgYW55b25lIHRocmVhdGVuZWQgYW4gYXBwZWFsIG9yIG90aGVyd2lz ZSBpbmRpY2F0ZWQgZXh0cmVtZSANZGlzY29udGVudD8gSWYgc28sIHBsZWFzZSBzdW1tYXJpc2Ug dGhlIGFyZWFzIG9mIGNvbmZsaWN0IGluIHNlcGFyYXRlIGVtYWlsIA1tZXNzYWdlcyB0byB0aGUg UmVzcG9uc2libGUgQXJlYSBEaXJlY3Rvci4gKEl0IHNob3VsZCBiZSBpbiBhIHNlcGFyYXRlIGVt YWlsIA1iZWNhdXNlIHRoaXMgcXVlc3Rpb25uYWlyZSBpcyBwdWJsaWNseSBhdmFpbGFibGUuKQ0K Ck5vLg0KCigxMSkgSWRlbnRpZnkgYW55IElEIG5pdHMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhh cyBmb3VuZCBpbiB0aGlzIGRvY3VtZW50LiANKFNlZSBodHRwOi8vd3d3LmlldGYub3JnL3Rvb2xz L2lkbml0cy8gYW5kIHRoZSBJbnRlcm5ldC1EcmFmdHMgQ2hlY2tsaXN0KS4gDUJvaWxlcnBsYXRl IGNoZWNrcyBhcmUgbm90IGVub3VnaDsgdGhpcyBjaGVjayBuZWVkcyB0byBiZSB0aG9yb3VnaC4N CgpObyBpc3N1ZXMgZm91bmQuDQoKKDEyKSBEZXNjcmliZSBob3cgdGhlIGRvY3VtZW50IG1lZXRz IGFueSByZXF1aXJlZCBmb3JtYWwgcmV2aWV3IGNyaXRlcmlhLCBzdWNoIA1hcyB0aGUgTUlCIERv Y3RvciwgbWVkaWEgdHlwZSwgYW5kIFVSSSB0eXBlIHJldmlld3MuDQoKTm90IGFwcGxpY2FibGUu DQoKKDEzKSBIYXZlIGFsbCByZWZlcmVuY2VzIHdpdGhpbiB0aGlzIGRvY3VtZW50IGJlZW4gaWRl bnRpZmllZCBhcyBlaXRoZXIgbm9ybWF0aXZlIA1vciBpbmZvcm1hdGl2ZT8NCgpZZXMuDQoKKDE0 KSBBcmUgdGhlcmUgbm9ybWF0aXZlIHJlZmVyZW5jZXMgdG8gZG9jdW1lbnRzIHRoYXQgYXJlIG5v dCByZWFkeSBmb3IgDWFkdmFuY2VtZW50IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhciBz dGF0ZT8gSWYgc3VjaCBub3JtYXRpdmUgcmVmZXJlbmNlcyANZXhpc3QsIHdoYXQgaXMgdGhlIHBs YW4gZm9yIHRoZWlyIGNvbXBsZXRpb24/DQoKTm8uDQoKKDE1KSBBcmUgdGhlcmUgZG93bndhcmQg bm9ybWF0aXZlIHJlZmVyZW5jZXMgcmVmZXJlbmNlcyAoc2VlIFJGQyAzOTY3KT8gSWYgc28sIA1s aXN0IHRoZXNlIGRvd253YXJkIHJlZmVyZW5jZXMgdG8gc3VwcG9ydCB0aGUgQXJlYSBEaXJlY3Rv ciBpbiB0aGUgTGFzdCBDYWxsIA1wcm9jZWR1cmUuDQoKTm8gZG93bndhcmQgcmVmZXJlbmNlcy4N CgooMTYpIFdpbGwgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudCBjaGFuZ2UgdGhlIHN0YXR1 cyBvZiBhbnkgZXhpc3RpbmcgUkZDcz8gQXJlIA10aG9zZSBSRkNzIGxpc3RlZCBvbiB0aGUgdGl0 bGUgcGFnZSBoZWFkZXIsIGxpc3RlZCBpbiB0aGUgYWJzdHJhY3QsIGFuZCBkaXNjdXNzZWQgaW4g DXRoZSBpbnRyb2R1Y3Rpb24/IElmIHRoZSBSRkNzIGFyZSBub3QgbGlzdGVkIGluIHRoZSBBYnN0 cmFjdCBhbmQgSW50cm9kdWN0aW9uLCANZXhwbGFpbiB3aHksIGFuZCBwb2ludCB0byB0aGUgcGFy dCBvZiB0aGUgZG9jdW1lbnQgd2hlcmUgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGlzIA1kb2N1bWVu dCB0byB0aGUgb3RoZXIgUkZDcyBpcyBkaXNjdXNzZWQuIElmIHRoaXMgaW5mb3JtYXRpb24gaXMg bm90IGluIHRoZSANZG9jdW1lbnQsIGV4cGxhaW4gd2h5IHRoZSBXRyBjb25zaWRlcnMgaXQgdW5u ZWNlc3NhcnkuDQoKTm8uDQoKCigxNykgRGVzY3JpYmUgdGhlIERvY3VtZW50IFNoZXBoZXJkJ3Mg cmV2aWV3IG9mIHRoZSBJQU5BIGNvbnNpZGVyYXRpb25zIA1zZWN0aW9uLCBlc3BlY2lhbGx5IHdp dGggcmVnYXJkIHRvIGl0cyBjb25zaXN0ZW5jeSB3aXRoIHRoZSBib2R5IG9mIHRoZSBkb2N1bWVu dC4gDUNvbmZpcm0gdGhhdCBhbGwgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0aGF0IHRoZSBkb2N1bWVu dCBtYWtlcyBhcmUgYXNzb2NpYXRlZCB3aXRoIA10aGUgYXBwcm9wcmlhdGUgcmVzZXJ2YXRpb25z IGluIElBTkEgcmVnaXN0cmllcy4gQ29uZmlybSB0aGF0IGFueSByZWZlcmVuY2VkIElBTkEgDXJl Z2lzdHJpZXMgaGF2ZSBiZWVuIGNsZWFybHkgaWRlbnRpZmllZC4gQ29uZmlybSB0aGF0IG5ld2x5 IGNyZWF0ZWQgSUFOQSByZWdpc3RyaWVzIA1pbmNsdWRlIGEgZGV0YWlsZWQgc3BlY2lmaWNhdGlv biBvZiB0aGUgaW5pdGlhbCBjb250ZW50cyBmb3IgdGhlIHJlZ2lzdHJ5LCB0aGF0IA1hbGxvY2F0 aW9ucyBwcm9jZWR1cmVzIGZvciBmdXR1cmUgcmVnaXN0cmF0aW9ucyBhcmUgZGVmaW5lZCwgYW5k IGEgcmVhc29uYWJsZSBuYW1lIA1mb3IgdGhlIG5ldyByZWdpc3RyeSBoYXMgYmVlbiBzdWdnZXN0 ZWQgKHNlZSBSRkMgNTIyNikuDQoKSSBoYXZlIHJldmlld2VkIHRoZSBJQU5BIENvbnNpZGVyYXRp b25zLCBhbmQgY29uZmlybSB0aGF0IHRoZSByZWZlcmVuY2VzIHRvIA1yZWdpc3RyaWVzIGFyZSBj bGVhciwgYW5kIHRoZSBjb250ZW50cyBhbmQgcG9saWNpZXMgd2VsbC1kZWZpbmVkLg0KCigxOCkg TGlzdCBhbnkgbmV3IElBTkEgcmVnaXN0cmllcyB0aGF0IHJlcXVpcmUgRXhwZXJ0IFJldmlldyBm b3IgZnV0dXJlIA1hbGxvY2F0aW9ucy4gUHJvdmlkZSBhbnkgcHVibGljIGd1aWRhbmNlIHRoYXQg dGhlIElFU0cgd291bGQgZmluZCB1c2VmdWwgaW4gDXNlbGVjdGluZyB0aGUgSUFOQSBFeHBlcnRz IGZvciB0aGVzZSBuZXcgcmVnaXN0cmllcy4NCgpOb25lLg0KCigxOSkgRGVzY3JpYmUgcmV2aWV3 cyBhbmQgYXV0b21hdGVkIGNoZWNrcyBwZXJmb3JtZWQgYnkgdGhlIERvY3VtZW50IA1TaGVwaGVy ZCB0byB2YWxpZGF0ZSBzZWN0aW9ucyBvZiB0aGUgZG9jdW1lbnQgd3JpdHRlbiBpbiBhIGZvcm1h bCBsYW5ndWFnZSwgc3VjaCANYXMgWE1MIGNvZGUsIEJORiBydWxlcywgTUlCIGRlZmluaXRpb25z LCBldGMuDQ1Ob3QgYXBwbGljYWJsZS4gVGhlIGRvY3VtZW50IGNvbnRhaW5zIG5vIGZvcm1hbCBs YW5ndWFnZS4NDQ0= --_004_28EBD44EA702D74DB2B6AABD0511BBEF1FE022xmbrcdx06ciscocom_-- From stephen.farrell@cs.tcd.ie Thu Nov 15 02:07:54 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 910D621F8549; Thu, 15 Nov 2012 02:07:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJWyiy5j5a8I; Thu, 15 Nov 2012 02:07:53 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 09E5921F853C; Thu, 15 Nov 2012 02:07:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A6451BE1C; Thu, 15 Nov 2012 10:07:28 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZtGFTyRfwIO; Thu, 15 Nov 2012 10:07:28 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.44.71.235]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F2CB3BDCC; Thu, 15 Nov 2012 10:07:27 +0000 (GMT) Message-ID: <50A4BEDF.9050308@cs.tcd.ie> Date: Thu, 15 Nov 2012 10:07:27 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Susan Thomson (sethomso)" References: <28EBD44EA702D74DB2B6AABD0511BBEF1FE022@xmb-rcd-x06.cisco.com> In-Reply-To: <28EBD44EA702D74DB2B6AABD0511BBEF1FE022@xmb-rcd-x06.cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nea@ietf.org" , IESG Secretary Subject: Re: [Nea] PT-EAP I-D Ready for IESG Evaluation 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, 15 Nov 2012 10:07:54 -0000 Thanks Susan, I'll get the AD review back to you soon's I can. Cheers, S. On 11/15/2012 01:57 AM, Susan Thomson (sethomso) wrote: > Stephen > > The PT-EAP I-D (draft-ietf-nea-pt-eap-05.txt) has completed WG Last Call and is ready for IESG evaluation as Proposed Standard. > > I am document shepherd and the write-up is attached. > > Thanks > Susan > From stephen.farrell@cs.tcd.ie Sun Nov 18 18:45:29 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 7716521F84D0 for ; Sun, 18 Nov 2012 18:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.766 X-Spam-Level: X-Spam-Status: No, score=-101.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, SARE_FWDLOOK=1.666, 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 2fxSXLuJpfH6 for ; Sun, 18 Nov 2012 18:45:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6282C21F84CF for ; Sun, 18 Nov 2012 18:45:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 274F4BE1E; Mon, 19 Nov 2012 02:45:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4npGt5s0gsMN; Mon, 19 Nov 2012 02:45:03 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.42.17.136]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A536CBDCC; Mon, 19 Nov 2012 02:45:03 +0000 (GMT) Message-ID: <50A99D2F.6090109@cs.tcd.ie> Date: Mon, 19 Nov 2012 02:45:03 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Susan Thomson (sethomso)" References: <28EBD44EA702D74DB2B6AABD0511BBEF1FE022@xmb-rcd-x06.cisco.com> In-Reply-To: <28EBD44EA702D74DB2B6AABD0511BBEF1FE022@xmb-rcd-x06.cisco.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nea@ietf.org" Subject: Re: [Nea] PT-EAP I-D Ready for IESG Evaluation 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 Nov 2012 02:45:29 -0000 Hi Susan, all, My AD review of this is below. I'm not sure if the chairs/authors would prefer make changes and/or argue before IETF LC (either is fine), so I'll mark this as being in AD eval while we figure that out. My first (numbered) list of questions are things I need to see answered before I start IETF LC. I'd say only question #1 might be tricky and its certainly ok to say that changes resulting from #2 & #3 will be put in after IETF LC, if some are needed, so #1 is (by far) the main deal. The other stuff you can consider as just some random-dude comments to take or leave:-) Cheers, S. questions I'd like answered before IETF LC: 1) Doesn't the non-existence of a standards-track EAP outer method that meets the needs of NEA (section 5, 2nd para) mean that this draft ought stay in the RFC editor queue until TEAP is done, and that TEAP ought be MTI for PT-EAP? (Which could be easily done if the wg wanted it.) If the wg's answer to is "no, its ok now", then I'm confused, since you seem to require a standards track EAP outer method that does not exist. Wouldn't that imply that this protocol cannot be implemented as currently specified and wouldn't that be a bad outcome for the IETF? 2) 4.1.1: If the PTS trusts the PTC this way then its crazy! If this is saying that a PTS ought not include code to validate syntax then that'd be broken. What's wrong here? Seems like maybe its a case of putting in too many words? I think this 2nd bullet list in 4.1.1 might be better if it disappeared. I also think the last paragraph on 4.1.1 should also disappear. Is that unreasonable or ok? 3) 4.2.5, last para: on what basis can one say that an EMA is effective, other than by definition, which doesn't seem convincing? I do agree that some EMA implementation might be effective but not that all things calling themselves an EMA are effective. It therefore seems wrong to have text that appears to depend on the effectiveness of all EMAs. ----------------- "random-dude" comments to take or leave: abstract: not sure if EAP needs expanding there or not abstract: s/tunnel method/EAP tunnel method/ ? intro: why does 1st sentence not use same terminology as abstract? intro: PB-TNC should be expanded intro: it might be good to briefly explain the terms inner and outer for EAP methods, but only if that text is not going to be contentious. 1.5: the forward-looking statement about what TCG might do in future seems out of place and was modified in the pt-tls draft I think. The same change seems right here. section 2: "MUST only" is odd, better would be to either s/only// or phrase this with a MUST NOT. 3.1: is the phrase "round robin exchange" clear or more confusing? It could be the latter since the term is mostly used in relation to load-balancing. That sentence is also pretty unclear, maybe what you mean is that there cannot be >1 PB-TNC batch in flight at any given time, if so, better to say so. I don't get the last sentence in the 3rd para here. 3.1: 3rd last and 2nd last paras are hard to get (at first reading at least). 3.1: last para seems unnecessary 3.3: It'd be good to give the figures names/captions to make 'em easier to reference. 3.3: 1st para, might be nice to name the 4 fields that are mandated. Also be good to say which of these fields are bog standard EAP and which are nea-specific, (in case someone codes up nea stuff to fit into some eap framwork or something). For example the start bit on p7 could be pt-eap-specific or not. section 4: This entire section seems to fall between two stools. On the one hand it could be an ab-initio analysis of threats to a generic PT-EAP, or else if could be a post-facto analysis of residual threats that need to be countered given the final PT-EAP design. Its hard to tell which is intended and I think the text oscilates between the two. I think making sure that's crystal clear would help here, in terms of giving the reader an easier time. 4.1.1: I don't get what "not observe" means here. How can a piece of code send out some bytes that it has not "observed" in some sense? 4.2, title is odd - what threat or countermeasure is nothing to do with security? suggest s/Security// in the title. (Same in 1st para of 4.2 and anywhere else.) 4.2.1: I'm not sure what "theft" means in the title here - presumably is involves a bad actor doing more than just copying the bytes, but what, in general? Maybe change title to "message confidentiality"? 4.2.1: who is "*the* adversary"? (my emphasis) Maybe s/the/an/ 4.2.1: "housed in" is an odd term likely to be easily misunderstood e.g. by non-native English speakers, "carried by" would seem better 4.2.1: EAP-FAST and EAP-TTLS could do with references on first use. (Same later for other methods, e.g. TEAP in 4.2.3.) 4.2.2: What'd it mean to creat a DoS against aspects of an assessment? I don't get that. 4.2.2: 1st para, malformed octets don't really seem like message fabrication. 4.2.2: last sentence - something wrong here, you can't say that unless you have an MTI outer EAP method that does guarantee that or else they all do, but do they all? 4.2.3: last sentence - is this missing a 2119 REQUIRED? 4.2.4: "encrypted and hashed" is pretty imprecise. 4.3: I think if the use of TLS is significant then you need a reference to 5246. Maybe also 5280 but that could be implied by TLS. 4.3: Is the parenthetic "using TLVs" text here stuff that ought go away? I think it probably is. section 6: the "MUST NOT observe" here seems like nonsense and nothing to do with 2119. 7.1: is "PT-EAP Versions" a top-level registry or part of something else? I think you can answer this by saying what URL you think would be good for accessing this registry. From shanna@juniper.net Mon Nov 19 14:38: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 5872521F8462 for ; Mon, 19 Nov 2012 14:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.623 X-Spam-Level: X-Spam-Status: No, score=-102.623 tagged_above=-999 required=5 tests=[AWL=-0.822, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666, UNRESOLVED_TEMPLATE=3.132, 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 EIiZHhPS7mqi for ; Mon, 19 Nov 2012 14:38:08 -0800 (PST) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 7028F21F84E6 for ; Mon, 19 Nov 2012 14:38:08 -0800 (PST) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUKq0ziCOLM4HUXBNnQ9iEmeg/KoZkukJ@postini.com; Mon, 19 Nov 2012 14:38:08 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Nov 2012 14:37:31 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Mon, 19 Nov 2012 14:37:31 -0800 Received: from CO9EHSOBE020.bigfish.com (207.46.163.24) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 19 Nov 2012 14:39:37 -0800 Received: from mail148-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE020.bigfish.com (10.236.130.83) with Microsoft SMTP Server id 14.1.225.23; Mon, 19 Nov 2012 22:37:30 +0000 Received: from mail148-co9 (localhost [127.0.0.1]) by mail148-co9-R.bigfish.com (Postfix) with ESMTP id 9D1698800E1 for ; Mon, 19 Nov 2012 22:37:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -24 X-BigFish: PS-24(zz9371I542M1432I4015Izz1de0h1202h1d1ah1d2ahzz1033IL8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h15d0l1155h) Received: from mail148-co9 (localhost.localdomain [127.0.0.1]) by mail148-co9 (MessageSwitch) id 1353364647686750_6091; Mon, 19 Nov 2012 22:37:27 +0000 (UTC) Received: from CO9EHSMHS030.bigfish.com (unknown [10.236.132.252]) by mail148-co9.bigfish.com (Postfix) with ESMTP id A530958005E; Mon, 19 Nov 2012 22:37:27 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by CO9EHSMHS030.bigfish.com (10.236.130.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 19 Nov 2012 22:37:20 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.12.225]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0233.002; Mon, 19 Nov 2012 22:37:19 +0000 From: Stephen Hanna To: Stephen Farrell Thread-Topic: [Nea] PT-EAP I-D Ready for IESG Evaluation Thread-Index: AQHNwtSZN/2pZMSZSky8DUtOu+QtBZfwehaAgAExoFA= Date: Mon, 19 Nov 2012 22:37:18 +0000 Message-ID: References: <28EBD44EA702D74DB2B6AABD0511BBEF1FE022@xmb-rcd-x06.cisco.com> <50A99D2F.6090109@cs.tcd.ie> In-Reply-To: <50A99D2F.6090109@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CS.TCD.IE$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "nea@ietf.org" Subject: Re: [Nea] PT-EAP I-D Ready for IESG Evaluation 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 Nov 2012 22:38:09 -0000 Stephen, Thanks for your prompt review and solid comments. I have talked with Susan and with the spec editors. We agreed that it's best to address your suggestions before we send the document off for IETF Last Call. Otherwise, we'd just be wasting the time of IETF Last Call participants because they'd be reviewing a document that wasn't quite done yet. The spec editors are working up a response now and should have it for you shortly. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Stephen Farrell > Sent: Sunday, November 18, 2012 9:45 PM > To: Susan Thomson (sethomso) > Cc: nea@ietf.org > Subject: Re: [Nea] PT-EAP I-D Ready for IESG Evaluation >=20 >=20 > Hi Susan, all, >=20 > My AD review of this is below. I'm not sure if the > chairs/authors would prefer make changes and/or argue > before IETF LC (either is fine), so I'll mark this as > being in AD eval while we figure that out. >=20 > My first (numbered) list of questions are things I > need to see answered before I start IETF LC. I'd say > only question #1 might be tricky and its certainly > ok to say that changes resulting from #2 & #3 will > be put in after IETF LC, if some are needed, so > #1 is (by far) the main deal. >=20 > The other stuff you can consider as just some > random-dude comments to take or leave:-) >=20 > Cheers, > S. >=20 > questions I'd like answered before IETF LC: >=20 > 1) Doesn't the non-existence of a standards-track EAP outer > method that meets the needs of NEA (section 5, 2nd para) > mean that this draft ought stay in the RFC editor queue > until TEAP is done, and that TEAP ought be MTI for PT-EAP? > (Which could be easily done if the wg wanted it.) > If the wg's answer to is "no, its ok now", then I'm > confused, since you seem to require a standards track EAP > outer method that does not exist. Wouldn't that imply that > this protocol cannot be implemented as currently specified > and wouldn't that be a bad outcome for the IETF? >=20 > 2) 4.1.1: If the PTS trusts the PTC this way then its > crazy! If this is saying that a PTS ought not include code > to validate syntax then that'd be broken. What's wrong > here? Seems like maybe its a case of putting in too many > words? I think this 2nd bullet list in 4.1.1 might be > better if it disappeared. I also think the last paragraph > on 4.1.1 should also disappear. Is that unreasonable or ok? >=20 > 3) 4.2.5, last para: on what basis can one say that an EMA > is effective, other than by definition, which doesn't seem > convincing? I do agree that some EMA implementation might > be effective but not that all things calling themselves an > EMA are effective. It therefore seems wrong to have text > that appears to depend on the effectiveness of all EMAs. >=20 > ----------------- >=20 > "random-dude" comments to take or leave: >=20 > abstract: not sure if EAP needs expanding there or not >=20 > abstract: s/tunnel method/EAP tunnel method/ ? >=20 > intro: why does 1st sentence not use same terminology as > abstract? >=20 > intro: PB-TNC should be expanded >=20 > intro: it might be good to briefly explain the terms inner > and outer for EAP methods, but only if that text is not > going to be contentious. >=20 > 1.5: the forward-looking statement about what TCG might do > in future seems out of place and was modified in the pt-tls > draft I think. The same change seems right here. >=20 > section 2: "MUST only" is odd, better would be to either > s/only// or phrase this with a MUST NOT. >=20 > 3.1: is the phrase "round robin exchange" clear or more > confusing? It could be the latter since the term is mostly > used in relation to load-balancing. That sentence is also > pretty unclear, maybe what you mean is that there cannot be > >1 PB-TNC batch in flight at any given time, if so, better > to say so. I don't get the last sentence in the 3rd para > here. >=20 > 3.1: 3rd last and 2nd last paras are hard to get (at first > reading at least). >=20 > 3.1: last para seems unnecessary >=20 > 3.3: It'd be good to give the figures names/captions to > make 'em easier to reference. >=20 > 3.3: 1st para, might be nice to name the 4 fields that are > mandated. Also be good to say which of these fields are bog > standard EAP and which are nea-specific, (in case someone > codes up nea stuff to fit into some eap framwork or > something). For example the start bit on p7 could be > pt-eap-specific or not. >=20 > section 4: This entire section seems to fall between two > stools. On the one hand it could be an ab-initio analysis > of threats to a generic PT-EAP, or else if could be a > post-facto analysis of residual threats that need to be > countered given the final PT-EAP design. Its hard to tell > which is intended and I think the text oscilates between > the two. I think making sure that's crystal clear would > help here, in terms of giving the reader an easier time. >=20 > 4.1.1: I don't get what "not observe" means here. How can a > piece of code send out some bytes that it has not > "observed" in some sense? >=20 > 4.2, title is odd - what threat or countermeasure is > nothing to do with security? suggest s/Security// in the > title. (Same in 1st para of 4.2 and anywhere else.) >=20 > 4.2.1: I'm not sure what "theft" means in the title here - > presumably is involves a bad actor doing more than just > copying the bytes, but what, in general? Maybe change > title to "message confidentiality"? >=20 > 4.2.1: who is "*the* adversary"? (my emphasis) Maybe > s/the/an/ >=20 > 4.2.1: "housed in" is an odd term likely to be easily > misunderstood e.g. by non-native English speakers, "carried > by" would seem better >=20 > 4.2.1: EAP-FAST and EAP-TTLS could do with references on > first use. (Same later for other methods, e.g. TEAP in > 4.2.3.) >=20 > 4.2.2: What'd it mean to creat a DoS against aspects of > an assessment? I don't get that. >=20 > 4.2.2: 1st para, malformed octets don't really seem like > message fabrication. >=20 > 4.2.2: last sentence - something wrong here, you can't > say that unless you have an MTI outer EAP method that > does guarantee that or else they all do, but do they > all? >=20 > 4.2.3: last sentence - is this missing a 2119 REQUIRED? >=20 > 4.2.4: "encrypted and hashed" is pretty imprecise. >=20 > 4.3: I think if the use of TLS is significant then you > need a reference to 5246. Maybe also 5280 but that could > be implied by TLS. >=20 > 4.3: Is the parenthetic "using TLVs" text here stuff that > ought go away? I think it probably is. >=20 > section 6: the "MUST NOT observe" here seems like nonsense > and nothing to do with 2119. >=20 > 7.1: is "PT-EAP Versions" a top-level registry or part of > something else? I think you can answer this by saying > what URL you think would be good for accessing this > registry. > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From stephen.farrell@cs.tcd.ie Mon Nov 19 14:46:45 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 47D5321F872A for ; Mon, 19 Nov 2012 14:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.599 X-Spam-Level: X-Spam-Status: No, score=-101.599 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, SARE_FWDLOOK=1.666, 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 mLBeQ3oul79x for ; Mon, 19 Nov 2012 14:46:44 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 038DC21F8720 for ; Mon, 19 Nov 2012 14:46:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 033BDBE27; Mon, 19 Nov 2012 22:46:20 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEYvcHHgLInt; Mon, 19 Nov 2012 22:46:18 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.42.17.136]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 26146BE25; Mon, 19 Nov 2012 22:46:18 +0000 (GMT) Message-ID: <50AAB6B9.4040005@cs.tcd.ie> Date: Mon, 19 Nov 2012 22:46:17 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stephen Hanna References: <28EBD44EA702D74DB2B6AABD0511BBEF1FE022@xmb-rcd-x06.cisco.com> <50A99D2F.6090109@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nea@ietf.org" Subject: Re: [Nea] PT-EAP I-D Ready for IESG Evaluation 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 Nov 2012 22:46:45 -0000 Thanks Steve, I've marked this as revised I-D needed and look forward to the editors' response, Cheers, S. On 11/19/2012 10:37 PM, Stephen Hanna wrote: > Stephen, > > Thanks for your prompt review and solid comments. I have > talked with Susan and with the spec editors. We agreed > that it's best to address your suggestions before we send > the document off for IETF Last Call. Otherwise, we'd just > be wasting the time of IETF Last Call participants because > they'd be reviewing a document that wasn't quite done yet. > > The spec editors are working up a response now and should > have it for you shortly. > > Thanks, > > Steve > >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of >> Stephen Farrell >> Sent: Sunday, November 18, 2012 9:45 PM >> To: Susan Thomson (sethomso) >> Cc: nea@ietf.org >> Subject: Re: [Nea] PT-EAP I-D Ready for IESG Evaluation >> >> >> Hi Susan, all, >> >> My AD review of this is below. I'm not sure if the >> chairs/authors would prefer make changes and/or argue >> before IETF LC (either is fine), so I'll mark this as >> being in AD eval while we figure that out. >> >> My first (numbered) list of questions are things I >> need to see answered before I start IETF LC. I'd say >> only question #1 might be tricky and its certainly >> ok to say that changes resulting from #2 & #3 will >> be put in after IETF LC, if some are needed, so >> #1 is (by far) the main deal. >> >> The other stuff you can consider as just some >> random-dude comments to take or leave:-) >> >> Cheers, >> S. >> >> questions I'd like answered before IETF LC: >> >> 1) Doesn't the non-existence of a standards-track EAP outer >> method that meets the needs of NEA (section 5, 2nd para) >> mean that this draft ought stay in the RFC editor queue >> until TEAP is done, and that TEAP ought be MTI for PT-EAP? >> (Which could be easily done if the wg wanted it.) >> If the wg's answer to is "no, its ok now", then I'm >> confused, since you seem to require a standards track EAP >> outer method that does not exist. Wouldn't that imply that >> this protocol cannot be implemented as currently specified >> and wouldn't that be a bad outcome for the IETF? >> >> 2) 4.1.1: If the PTS trusts the PTC this way then its >> crazy! If this is saying that a PTS ought not include code >> to validate syntax then that'd be broken. What's wrong >> here? Seems like maybe its a case of putting in too many >> words? I think this 2nd bullet list in 4.1.1 might be >> better if it disappeared. I also think the last paragraph >> on 4.1.1 should also disappear. Is that unreasonable or ok? >> >> 3) 4.2.5, last para: on what basis can one say that an EMA >> is effective, other than by definition, which doesn't seem >> convincing? I do agree that some EMA implementation might >> be effective but not that all things calling themselves an >> EMA are effective. It therefore seems wrong to have text >> that appears to depend on the effectiveness of all EMAs. >> >> ----------------- >> >> "random-dude" comments to take or leave: >> >> abstract: not sure if EAP needs expanding there or not >> >> abstract: s/tunnel method/EAP tunnel method/ ? >> >> intro: why does 1st sentence not use same terminology as >> abstract? >> >> intro: PB-TNC should be expanded >> >> intro: it might be good to briefly explain the terms inner >> and outer for EAP methods, but only if that text is not >> going to be contentious. >> >> 1.5: the forward-looking statement about what TCG might do >> in future seems out of place and was modified in the pt-tls >> draft I think. The same change seems right here. >> >> section 2: "MUST only" is odd, better would be to either >> s/only// or phrase this with a MUST NOT. >> >> 3.1: is the phrase "round robin exchange" clear or more >> confusing? It could be the latter since the term is mostly >> used in relation to load-balancing. That sentence is also >> pretty unclear, maybe what you mean is that there cannot be >>> 1 PB-TNC batch in flight at any given time, if so, better >> to say so. I don't get the last sentence in the 3rd para >> here. >> >> 3.1: 3rd last and 2nd last paras are hard to get (at first >> reading at least). >> >> 3.1: last para seems unnecessary >> >> 3.3: It'd be good to give the figures names/captions to >> make 'em easier to reference. >> >> 3.3: 1st para, might be nice to name the 4 fields that are >> mandated. Also be good to say which of these fields are bog >> standard EAP and which are nea-specific, (in case someone >> codes up nea stuff to fit into some eap framwork or >> something). For example the start bit on p7 could be >> pt-eap-specific or not. >> >> section 4: This entire section seems to fall between two >> stools. On the one hand it could be an ab-initio analysis >> of threats to a generic PT-EAP, or else if could be a >> post-facto analysis of residual threats that need to be >> countered given the final PT-EAP design. Its hard to tell >> which is intended and I think the text oscilates between >> the two. I think making sure that's crystal clear would >> help here, in terms of giving the reader an easier time. >> >> 4.1.1: I don't get what "not observe" means here. How can a >> piece of code send out some bytes that it has not >> "observed" in some sense? >> >> 4.2, title is odd - what threat or countermeasure is >> nothing to do with security? suggest s/Security// in the >> title. (Same in 1st para of 4.2 and anywhere else.) >> >> 4.2.1: I'm not sure what "theft" means in the title here - >> presumably is involves a bad actor doing more than just >> copying the bytes, but what, in general? Maybe change >> title to "message confidentiality"? >> >> 4.2.1: who is "*the* adversary"? (my emphasis) Maybe >> s/the/an/ >> >> 4.2.1: "housed in" is an odd term likely to be easily >> misunderstood e.g. by non-native English speakers, "carried >> by" would seem better >> >> 4.2.1: EAP-FAST and EAP-TTLS could do with references on >> first use. (Same later for other methods, e.g. TEAP in >> 4.2.3.) >> >> 4.2.2: What'd it mean to creat a DoS against aspects of >> an assessment? I don't get that. >> >> 4.2.2: 1st para, malformed octets don't really seem like >> message fabrication. >> >> 4.2.2: last sentence - something wrong here, you can't >> say that unless you have an MTI outer EAP method that >> does guarantee that or else they all do, but do they >> all? >> >> 4.2.3: last sentence - is this missing a 2119 REQUIRED? >> >> 4.2.4: "encrypted and hashed" is pretty imprecise. >> >> 4.3: I think if the use of TLS is significant then you >> need a reference to 5246. Maybe also 5280 but that could >> be implied by TLS. >> >> 4.3: Is the parenthetic "using TLVs" text here stuff that >> ought go away? I think it probably is. >> >> section 6: the "MUST NOT observe" here seems like nonsense >> and nothing to do with 2119. >> >> 7.1: is "PT-EAP Versions" a top-level registry or part of >> something else? I think you can answer this by saying >> what URL you think would be good for accessing this >> registry. >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea > > > > From ncamwing@cisco.com Mon Nov 26 19:51: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 D3C2921F8751 for ; Mon, 26 Nov 2012 19:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.933 X-Spam-Level: X-Spam-Status: No, score=-8.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_FWDLOOK=1.666] 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 btnEDuZf9r11 for ; Mon, 26 Nov 2012 19:51:33 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1D62621F8469 for ; Mon, 26 Nov 2012 19:51:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13493; q=dns/txt; s=iport; t=1353988293; x=1355197893; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=27pvg4os2RFrE49llH6dGbYHHN/M4v9AVheuI3QF4VU=; b=PetNQPf6jT185ccj1DJkhUaOjZ6LPFs2YYNfN8v4dWiQu7JWmVBnPkc/ Tx7om3tlbv3jHuWcyE4cWN6jzXaUmIHDP1wu9OFi6o7UxacschO/pBfq5 6TgpD1HKpCgh+6CqN9hd3FuWfAswGlAFLEa68Fy3eZBIJ4PDqkK7Gfrko c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHY4tFCtJXG//2dsb2JhbABEwCiBCYIgAQQBAQFkBwQHEgEIIksLJQIEAQ0FCIgFDK9+kDQEjDgKg1VhA6ZFgmINgV8CBQIXBhg X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146461389" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 27 Nov 2012 03:51:17 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAR3pHJg020685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 03:51:17 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 21:51:16 -0600 From: "Nancy Cam-Winget (ncamwing)" To: Stephen Farrell , "Susan Thomson (sethomso)" Thread-Topic: [Nea] PT-EAP I-D Ready for IESG Evaluation Thread-Index: AQHNwtSZN/2pZMSZSky8DUtOu+QtBZfw3qyAgAwfCAA= Date: Tue, 27 Nov 2012 03:51:16 +0000 Message-ID: In-Reply-To: <50A99D2F.6090109@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.21.71.142] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nea@ietf.org" Subject: Re: [Nea] PT-EAP I-D Ready for IESG Evaluation 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 Nov 2012 03:51:35 -0000 Hi Stephen, Thanks for your prompt and thorough review of the PT-EAP spec. I've reviewed the comments that you sent and have provided further comments/responses below. If we can agree on all the updates/comments, I can churn another version then=8A. Thanks again, Nancy P.S. The comments were very helpful :-) On 11/18/12 6:45 PM, "Stephen Farrell" wrote: > >Hi Susan, all, > >My AD review of this is below. I'm not sure if the >chairs/authors would prefer make changes and/or argue >before IETF LC (either is fine), so I'll mark this as >being in AD eval while we figure that out. [NCW] As Steve mentioned in his earlier email, we'd like to get these straightened out before we go to IETF LC. > >My first (numbered) list of questions are things I >need to see answered before I start IETF LC. I'd say >only question #1 might be tricky and its certainly >ok to say that changes resulting from #2 & #3 will >be put in after IETF LC, if some are needed, so >#1 is (by far) the main deal. > >The other stuff you can consider as just some >random-dude comments to take or leave:-) > >Cheers, >S. > >questions I'd like answered before IETF LC: > >1) Doesn't the non-existence of a standards-track EAP outer >method that meets the needs of NEA (section 5, 2nd para) >mean that this draft ought stay in the RFC editor queue >until TEAP is done, and that TEAP ought be MTI for PT-EAP? >(Which could be easily done if the wg wanted it.) >If the wg's answer to is "no, its ok now", then I'm >confused, since you seem to require a standards track EAP >outer method that does not exist. Wouldn't that imply that >this protocol cannot be implemented as currently specified >and wouldn't that be a bad outcome for the IETF? [NCW] The NEA WG discussed this at length and agreed that the spec should not wait for TEAP to be standardized. There was consensus that the already industry established/used tunnel methods, e.g. EAP-FAST, EAP-TTLS and PEAP met the requirements in section 5 of PT-EAP; while these are not standardized by the IETF, several of them are documented in the IETF as informational RFCs. Further consensus indicated that the group both, did not want to wait for TEAP's standardization and that there would be some benefit if using the NEA protocols with the already existing tunnel methods. > >2) 4.1.1: If the PTS trusts the PTC this way then its >crazy! If this is saying that a PTS ought not include code >to validate syntax then that'd be broken. What's wrong >here? Seems like maybe its a case of putting in too many >words? I think this 2nd bullet list in 4.1.1 might be >better if it disappeared. I also think the last paragraph >on 4.1.1 should also disappear. Is that unreasonable or ok? [NCW] Your rationale makes sense and request is reasonable. I think the intent was to provide a warning to the PTS implementations of malicious PTC behaviors. Should we just include a sentence as such? E.g. "Since the Posture Transport Server can not validate the trustworthiness of the Posture Transport Client; the Posture Transport Server should protect itself accordingly." Since 4.1.2 follows the same template, I presume you'd also like us to follow the same updates as we do for 4.1.1? > >3) 4.2.5, last para: on what basis can one say that an EMA >is effective, other than by definition, which doesn't seem >convincing? I do agree that some EMA implementation might >be effective but not that all things calling themselves an >EMA are effective. It therefore seems wrong to have text >that appears to depend on the effectiveness of all EMAs. [NCW] It is true that it is difficult to guarantee all EMA's implementations to be effective. Since there are some EMA's believed to be effective as well as the charter stating "the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints", the group felt that a SHOULD clause be included. If there's "text that appears to depend on the effectiveness of all EMAs", could you please point out the exact text so that we can better address your concern? > >----------------- > >"random-dude" comments to take or leave: > >abstract: not sure if EAP needs expanding there or not [NCW] Since it's the first reference, it does make sense to expand it=8Aso will do. > >abstract: s/tunnel method/EAP tunnel method/ ? [NCW] Thanks for the find! Will do=8A > >intro: why does 1st sentence not use same terminology as >abstract? [NCW] No reason, so we'll make it consistent. > >intro: PB-TNC should be expanded [NCW] OK. We'll also add a pointer to the PB-TNC reference. > >intro: it might be good to briefly explain the terms inner >and outer for EAP methods, but only if that text is not >going to be contentious. [NCW] I don't think it would be contentious. We can put this in the last paragraph of section 1, which is the first place that we use the term "inner EAP method". > >1.5: the forward-looking statement about what TCG might do >in future seems out of place and was modified in the pt-tls >draft I think. The same change seems right here. [NCW] Sounds good=8A.will do > >section 2: "MUST only" is odd, better would be to either >s/only// or phrase this with a MUST NOT. [NCW] OK, we can just remove "only" > >3.1: is the phrase "round robin exchange" clear or more >confusing? It could be the latter since the term is mostly >used in relation to load-balancing. That sentence is also >pretty unclear, maybe what you mean is that there cannot be >>1 PB-TNC batch in flight at any given time, if so, better >to say so. I don't get the last sentence in the 3rd para >here. [NCW] We can change the sentence with round-robin from: The NEA Client and NEA Server then engage in a round-robin exchange with one PB-TNC batch in flight at a time. to this: The NEA Client and NEA Server then take turns sending a PB-TNC batch. No more than one PB-TNC batch can ever be in flight at any given time. It seems that the sentence you don't understand is this one: This message may be empty (not contain any data) if the NEA Server has just sent the last PB-TNC batch in the PB-TNC exchange. Is that right? The preceding sentence was this one: The data transport phase always ends with an EAP Response message from the NEA Client to the NEA Server. So the last message in the data transport phase goes from the NEA Client to the NEA Server. If the NEA Client doesn't have any PB-TNC batches to send, it just sends a PT-EAP message whose Data field is empty. Does that help you understand what we're trying to say? If so, perhaps we should change that confusing sentence to say: The Data field of this message may have zero length if the NEA Server has just sent the last PB-TNC batch in the PB-TNC exchange. > >3.1: 3rd last and 2nd last paras are hard to get (at first >reading at least). [NCW] Sorry. The 3rd last para is just saying that the success of PT-EAP does not mean that the overall authentication will succeed. Neither does the failure of PT-EAP mean that the overall authentication will fail. That depends on the policy configured by the administrator. Maybe they're just doing a posture check to see which machines are healthy for reporting purposes or maybe they don't keep unhealthy machines off the network but quarantine them. This is not always immediately clear to people when they read these specs. The 2nd last para says that you don't have to continue the PT-EAP exchange to the end. However, different EAP tunnel methods have different ways to stop an inner EAP method prematurely. Any suggestions for wording changes? > >3.1: last para seems unnecessary [NCW] The intent was to ensure that the sequencing is followed (e.g. A MUST). Is that inferred by it being section 3 (e.g. A normative section?). If that's the case, then we can remove the paragraph, otherwise, can you suggest how we can ensure the sequencing if adhered to? > >3.3: It'd be good to give the figures names/captions to >make 'em easier to reference. [NCW] Sure will do (something new to learn in the xml script :-) > >3.3: 1st para, might be nice to name the 4 fields that are >mandated. Also be good to say which of these fields are bog >standard EAP and which are nea-specific, (in case someone >codes up nea stuff to fit into some eap framwork or >something). For example the start bit on p7 could be >pt-eap-specific or not. [NCW] Good point; will do. > >section 4: This entire section seems to fall between two >stools. On the one hand it could be an ab-initio analysis >of threats to a generic PT-EAP, or else if could be a >post-facto analysis of residual threats that need to be >countered given the final PT-EAP design. Its hard to tell >which is intended and I think the text oscilates between >the two. I think making sure that's crystal clear would >help here, in terms of giving the reader an easier time. [NCW] PT-EAP provides NO security protections at all. All of the security is provided by the EAP tunnel method and other components such as the EMA. So this sections attempts to describe the threats relevant to PT-EAP (and the NEA reference model) and translates those into a list of protections that the EAP tunnel method must provide and a few things that the PT-EAP implementer must do (e.g. be wary of data sent by the other side and expose the tls-unique value upward). Can you suggest ways to improve on what's written? > >4.1.1: I don't get what "not observe" means here. How can a >piece of code send out some bytes that it has not >"observed" in some sense? [NCW] How about we change it to "Disclose to unauthorized parties" instead? The intent is to ensure that the PTC and PTS not leak the info. > >4.2, title is odd - what threat or countermeasure is >nothing to do with security? suggest s/Security// in the >title. (Same in 1st para of 4.2 and anywhere else.) [NCW] OK=8Awill do. > >4.2.1: I'm not sure what "theft" means in the title here - >presumably is involves a bad actor doing more than just >copying the bytes, but what, in general? Maybe change >title to "message confidentiality"? [NCW] Sure=8Awill do. > >4.2.1: who is "*the* adversary"? (my emphasis) Maybe >s/the/an/ [NCW] Sure=8Awill do. > >4.2.1: "housed in" is an odd term likely to be easily >misunderstood e.g. by non-native English speakers, "carried >by" would seem better [NCW] Sure=8Awill do. > >4.2.1: EAP-FAST and EAP-TTLS could do with references on >first use. (Same later for other methods, e.g. TEAP in >4.2.3.) [NCW] They are already referenced in Section 1; would you like us To repeat them in this section as well? > >4.2.2: What'd it mean to creat a DoS against aspects of >an assessment? I don't get that. [NCW] One example would be to insert a PT-EAP message to tell a NEA Server that the endpoint is totally infected. This could cause the device to be blocked from accessing a critical resource, which would be a denial of service. > >4.2.2: 1st para, malformed octets don't really seem like >message fabrication. [NCW] Would it be better to change it to the example above? > >4.2.2: last sentence - something wrong here, you can't >say that unless you have an MTI outer EAP method that >does guarantee that or else they all do, but do they >all? [NCW] If the EAP tunnel method meets the requirements in section 5, it prevents undetected insertion of PT-EAP messages into a properly authorized exchange. All of the EAP tunnel methods described in section 4.3 meet those requirements. However, it would be inappropriate to make one of them MTI for PT-EAP because none of them is yet specified in a Standards Track RFC. > >4.2.3: last sentence - is this missing a 2119 REQUIRED? [NCW] Some reviewers objected to putting RFC 2119 text into a Security Considerations section. Therefore, we put all of the RFC 2119 requirements on EAP tunnel methods in section 5. > >4.2.4: "encrypted and hashed" is pretty imprecise. [NCW] How about we split the sentence into: "After the cryptographic authentication by the EAP tunnel method, the session can be protected cryptographically to provide confidentiality and source authenticity. Such protection prevents undetected modification that could create a denial of service situation." > >4.3: I think if the use of TLS is significant then you >need a reference to 5246. Maybe also 5280 but that could >be implied by TLS. [NCW] We do have a reference to RFC 5246. In fact, it's Normative. TLS does permit PGP certificates to be used so it seems wrong for us to reference RFC 5280. > >4.3: Is the parenthetic "using TLVs" text here stuff that >ought go away? I think it probably is. [NCW] Sure=8Awill do. > >section 6: the "MUST NOT observe" here seems like nonsense >and nothing to do with 2119. [NCW] Sure=8Awill do. > >7.1: is "PT-EAP Versions" a top-level registry or part of >something else? I think you can answer this by saying >what URL you think would be good for accessing this >registry. [NCW] It's Top levee registry. >_______________________________________________ >Nea mailing list >Nea@ietf.org >https://www.ietf.org/mailman/listinfo/nea From stephen.farrell@cs.tcd.ie Tue Nov 27 02:48:36 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 D7B4C21F8529 for ; Tue, 27 Nov 2012 02:48:36 -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=[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 dFuGabaq4W8m for ; Tue, 27 Nov 2012 02:48:35 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8EF21F8526 for ; Tue, 27 Nov 2012 02:48:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5758EBE5D; Tue, 27 Nov 2012 10:48:08 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOFG5M+ymBxQ; Tue, 27 Nov 2012 10:48:01 +0000 (GMT) Received: from [172.19.13.119] (unknown [83.141.77.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A8F9FBE32; Tue, 27 Nov 2012 10:48:01 +0000 (GMT) Message-ID: <50B49A61.4000209@cs.tcd.ie> Date: Tue, 27 Nov 2012 10:48:01 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Nancy Cam-Winget (ncamwing)" References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nea@ietf.org" Subject: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for IESG Evaluation) 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 Nov 2012 10:48:37 -0000 Hi Nancy, Thanks for that. Just splitting out the one non-nit thing, I'll respond to the rest in a bit. On 11/27/2012 03:51 AM, Nancy Cam-Winget (ncamwing) wrote: > > On 11/18/12 6:45 PM, "Stephen Farrell" wrote: > >> questions I'd like answered before IETF LC: >> >> 1) Doesn't the non-existence of a standards-track EAP outer >> method that meets the needs of NEA (section 5, 2nd para) >> mean that this draft ought stay in the RFC editor queue >> until TEAP is done, and that TEAP ought be MTI for PT-EAP? >> (Which could be easily done if the wg wanted it.) >> If the wg's answer to is "no, its ok now", then I'm >> confused, since you seem to require a standards track EAP >> outer method that does not exist. Wouldn't that imply that >> this protocol cannot be implemented as currently specified >> and wouldn't that be a bad outcome for the IETF? > > [NCW] The NEA WG discussed this at length and agreed that the spec > should not wait for TEAP to be standardized. There was consensus > that the already industry established/used tunnel methods, e.g. EAP-FAST, > EAP-TTLS and PEAP met the requirements in section 5 of PT-EAP; while > these are not standardized by the IETF, several of them are documented > in the IETF as informational RFCs. Further consensus indicated that the > group both, did not want to wait for TEAP's standardization and that there > would be some benefit if using the NEA protocols with the already existing > tunnel methods. Ok, good to have this recently documented. I guess the issue is that that plan leaves PT-EAP not really conforming with BCP 61 (the one that says you MUST almost always have strong security as MTI). [1] I'm sure that'll be a topic for discussion during IESG evaluation, so best if we're explicit about it now so we can point at this thread for the IESG. (Apologies for rehashing the WG discussion, but I reckon it'll be useful for the IESG.) I reckon the following options exist in principle. 1) Process PT-EAP as-is and have the discussion about BCP61 with the IESG. I guess the WG argument here is in section 5 of the document where it says that the outer EAP method MUST do what's needed and points at TEAP. 2) Pick one of the existing EAP methods and make that MTI. We can handle the downref in the IETF LC, so that's not an issue, if there's an existing method that would work for the WG. The draft could also say that we expect folks to migrate to a standards-track method in future. 3) The WG could change its mind and decide to wait on TEAP if the situation has moved on since this was discussed before. The draft takes approach #1, so unless you (the WG) want to change your mind I'm ok with progressing this on that basis, but we may need to have the discussion with the IESG. So, no response is needed to this, unless folks want to plump for #2 or #3 or something else. Thanks, S. [1] http://tools.ietf.org/html/bcp61 From stephen.farrell@cs.tcd.ie Tue Nov 27 03:50:54 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 29F2021F84BA for ; Tue, 27 Nov 2012 03:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.766 X-Spam-Level: X-Spam-Status: No, score=-101.766 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, SARE_FWDLOOK=1.666, 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 wMc4VwWAKE7j for ; Tue, 27 Nov 2012 03:50:52 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7051C21F842D for ; Tue, 27 Nov 2012 03:50:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BEB34BE25; Tue, 27 Nov 2012 11:50:27 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dY+Dj2ijKSwD; Tue, 27 Nov 2012 11:50:22 +0000 (GMT) Received: from [172.19.13.119] (unknown [83.141.77.130]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 49EA7BE1E; Tue, 27 Nov 2012 11:50:22 +0000 (GMT) Message-ID: <50B4A8FD.6070301@cs.tcd.ie> Date: Tue, 27 Nov 2012 11:50:21 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Nancy Cam-Winget (ncamwing)" References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "nea@ietf.org" Subject: Re: [Nea] PT-EAP I-D Ready for IESG Evaluation 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 Nov 2012 11:50:54 -0000 On the more nitty-bits... On 11/27/2012 03:51 AM, Nancy Cam-Winget (ncamwing) wrote: > Hi Stephen, > > Thanks for your prompt and thorough review of the PT-EAP spec. I've > reviewed the comments that you sent and have provided further > comments/responses below. > If we can agree on all the updates/comments, I can churn another version > thenŠ. > > Thanks again, > > Nancy > > P.S. The comments were very helpful :-) Great. But apologies for those that aren't:-) > On 11/18/12 6:45 PM, "Stephen Farrell" wrote: > >> >> Hi Susan, all, >> >> My AD review of this is below. I'm not sure if the >> chairs/authors would prefer make changes and/or argue >> before IETF LC (either is fine), so I'll mark this as >> being in AD eval while we figure that out. > [NCW] As Steve mentioned in his earlier email, we'd like to > get these straightened out before we go to IETF LC. > >> >> My first (numbered) list of questions are things I >> need to see answered before I start IETF LC. I'd say >> only question #1 might be tricky and its certainly >> ok to say that changes resulting from #2 & #3 will >> be put in after IETF LC, if some are needed, so >> #1 is (by far) the main deal. >> >> The other stuff you can consider as just some >> random-dude comments to take or leave:-) >> >> Cheers, >> S. >> >> questions I'd like answered before IETF LC: >> >> 1) Doesn't the non-existence of a standards-track EAP outer >> method that meets the needs of NEA (section 5, 2nd para) >> mean that this draft ought stay in the RFC editor queue >> until TEAP is done, and that TEAP ought be MTI for PT-EAP? >> (Which could be easily done if the wg wanted it.) >> If the wg's answer to is "no, its ok now", then I'm >> confused, since you seem to require a standards track EAP >> outer method that does not exist. Wouldn't that imply that >> this protocol cannot be implemented as currently specified >> and wouldn't that be a bad outcome for the IETF? > [NCW] The NEA WG discussed this at length and agreed that the spec > should not wait for TEAP to be standardized. There was consensus > that the already industry established/used tunnel methods, e.g. EAP-FAST, > EAP-TTLS and PEAP met the requirements in section 5 of PT-EAP; while > these are not standardized by the IETF, several of them are documented > in the IETF as informational RFCs. Further consensus indicated that the > group both, did not want to wait for TEAP's standardization and that there > would be some benefit if using the NEA protocols with the already existing > tunnel methods. See the other mail. > >> >> 2) 4.1.1: If the PTS trusts the PTC this way then its >> crazy! If this is saying that a PTS ought not include code >> to validate syntax then that'd be broken. What's wrong >> here? Seems like maybe its a case of putting in too many >> words? I think this 2nd bullet list in 4.1.1 might be >> better if it disappeared. I also think the last paragraph >> on 4.1.1 should also disappear. Is that unreasonable or ok? > > [NCW] Your rationale makes sense and request is reasonable. > I think the intent was to provide a warning to the PTS implementations of > malicious PTC behaviors. Should we just include a sentence as such? E.g. > "Since the Posture Transport Server can not validate the trustworthiness > of the Posture Transport Client; the Posture Transport Server should > protect > itself accordingly." > Since 4.1.2 follows the same template, I presume you'd also like us to > follow > the same updates as we do for 4.1.1? I think that'd be better. Maybe s/accordingly/appropriately/ >> 3) 4.2.5, last para: on what basis can one say that an EMA >> is effective, other than by definition, which doesn't seem >> convincing? I do agree that some EMA implementation might >> be effective but not that all things calling themselves an >> EMA are effective. It therefore seems wrong to have text >> that appears to depend on the effectiveness of all EMAs. > > [NCW] It is true that it is difficult to guarantee all EMA's > implementations to be effective. Since there are some EMA's > believed to be effective as well as the charter stating > "the protocols developed by the NEA WG must be designed to accommodate > emerging technologies for identifying and dealing with lying endpoints", > the group felt that a SHOULD clause be included. > > > If there's "text that appears to depend on the effectiveness > of all EMAs", could you please point out the exact text so > that we can better address your concern? I guess I meant this, from 3.4: If the tls-unique values of the NEA Client and NEA Server match and this is confirmed by the EMA, 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 value) so no man- in-the-middle is forwarding posture. The conclusion only holds for a "good" EMA, not for all EMAs. I guess you could fix by s/sent by the EMA/sent by a trustworthy EMA/ or similar. >> ----------------- >> >> "random-dude" comments to take or leave: Just to repeat the above. Feel free to just cut off discussion on these, we don't need to bottom out on any of this from my p-o-v, unless you want to, in which case, I'm fine to chat more. >> >> abstract: not sure if EAP needs expanding there or not > [NCW] Since it's the first reference, it does make sense to expand itŠso > will do. > >> >> abstract: s/tunnel method/EAP tunnel method/ ? > [NCW] Thanks for the find! Will doŠ > >> >> intro: why does 1st sentence not use same terminology as >> abstract? > [NCW] No reason, so we'll make it consistent. > >> >> intro: PB-TNC should be expanded > [NCW] OK. We'll also add a pointer to the PB-TNC reference. > >> >> intro: it might be good to briefly explain the terms inner >> and outer for EAP methods, but only if that text is not >> going to be contentious. > [NCW] I don't think it would be contentious. We can put this in the last > paragraph > of section 1, which is the first place that we use the term > "inner EAP method". > > >> >> 1.5: the forward-looking statement about what TCG might do >> in future seems out of place and was modified in the pt-tls >> draft I think. The same change seems right here. > [NCW] Sounds goodŠ.will do > >> >> section 2: "MUST only" is odd, better would be to either >> s/only// or phrase this with a MUST NOT. > [NCW] OK, we can just remove "only" > >> >> 3.1: is the phrase "round robin exchange" clear or more >> confusing? It could be the latter since the term is mostly >> used in relation to load-balancing. That sentence is also >> pretty unclear, maybe what you mean is that there cannot be >>> 1 PB-TNC batch in flight at any given time, if so, better >> to say so. I don't get the last sentence in the 3rd para >> here. > [NCW] We can change the sentence with round-robin from: > > The NEA Client and NEA Server then engage in a round-robin > exchange with one PB-TNC batch in flight at a time. > > to this: > > The NEA Client and NEA Server then take turns sending a > PB-TNC batch. No more than one PB-TNC batch can ever be > in flight at any given time. That's better I think. > > It seems that the sentence you don't understand is this one: > > This message may be empty (not contain any data) if the NEA > Server has just sent the last PB-TNC batch in the PB-TNC exchange. > Is that right? The preceding sentence was this one: > > The data transport phase always ends with an EAP Response > message from the NEA Client to the NEA Server. > > So the last message in the data transport phase goes from the > NEA Client to the NEA Server. If the NEA Client doesn't have > any PB-TNC batches to send, it just sends a PT-EAP message > whose Data field is empty. Does that help you understand what > we're trying to say? If so, perhaps we should change that > confusing sentence to say: > > The Data field of this message may have zero length if the NEA > Server has just sent the last PB-TNC batch in the PB-TNC exchange. Ok, got it now (I think:-) >> 3.1: 3rd last and 2nd last paras are hard to get (at first >> reading at least). > > [NCW] Sorry. The 3rd last para is just saying that the success of PT-EAP > does not mean that the overall authentication will succeed. Neither > does the failure of PT-EAP mean that the overall authentication will > fail. That depends on the policy configured by the administrator. > Maybe they're just doing a posture check to see which machines are > healthy for reporting purposes or maybe they don't keep unhealthy > machines off the network but quarantine them. This is not always > immediately clear to people when they read these specs. I think the text above would be useful to include maybe. > > The 2nd last para says that you don't have to continue the PT-EAP > exchange to the end. However, different EAP tunnel methods have > different ways to stop an inner EAP method prematurely. Any > suggestions for wording changes? 'Fraid not. But your explanations helped me. > >> >> 3.1: last para seems unnecessary > [NCW] The intent was to ensure that the sequencing is followed (e.g. A > MUST). > Is that inferred by it being section 3 (e.g. A normative section?). If > that's > the case, then we can remove the paragraph, otherwise, can you suggest how > we can ensure the sequencing if adhered to? Nope. I just think having RFC foo section bar say "you MUST follow the protocol in this section" seems moot. No harm to leave it, other than someone else may make the same comment, so it could consume cycles;-) >> 3.3: It'd be good to give the figures names/captions to >> make 'em easier to reference. > [NCW] Sure will do (something new to learn in the xml script :-) > >> >> 3.3: 1st para, might be nice to name the 4 fields that are >> mandated. Also be good to say which of these fields are bog >> standard EAP and which are nea-specific, (in case someone >> codes up nea stuff to fit into some eap framwork or >> something). For example the start bit on p7 could be >> pt-eap-specific or not. > [NCW] Good point; will do. > >> >> section 4: This entire section seems to fall between two >> stools. On the one hand it could be an ab-initio analysis >> of threats to a generic PT-EAP, or else if could be a >> post-facto analysis of residual threats that need to be >> countered given the final PT-EAP design. Its hard to tell >> which is intended and I think the text oscilates between >> the two. I think making sure that's crystal clear would >> help here, in terms of giving the reader an easier time. > > [NCW] PT-EAP provides NO security protections at all. > All of the security is provided by the EAP tunnel method and > other components such as the EMA. So this sections attempts > to describe the threats relevant to PT-EAP (and the NEA > reference model) and translates those into a list of protections that the > EAP tunnel method must provide and a few things that the > PT-EAP implementer must do (e.g. be wary of data sent by > the other side and expose the tls-unique value upward). > > Can you suggest ways to improve on what's written? Probably not - I'd only make it worse than it is now most likely;-) This comment is probably better ignored. >> 4.1.1: I don't get what "not observe" means here. How can a >> piece of code send out some bytes that it has not >> "observed" in some sense? > [NCW] How about we change it to "Disclose to unauthorized parties" > instead? The intent is to ensure that the PTC and PTS not leak the info. Great. > >> >> 4.2, title is odd - what threat or countermeasure is >> nothing to do with security? suggest s/Security// in the >> title. (Same in 1st para of 4.2 and anywhere else.) > [NCW] OKŠwill do. > >> >> 4.2.1: I'm not sure what "theft" means in the title here - >> presumably is involves a bad actor doing more than just >> copying the bytes, but what, in general? Maybe change >> title to "message confidentiality"? > [NCW] SureŠwill do. > >> >> 4.2.1: who is "*the* adversary"? (my emphasis) Maybe >> s/the/an/ > [NCW] SureŠwill do. > > >> >> 4.2.1: "housed in" is an odd term likely to be easily >> misunderstood e.g. by non-native English speakers, "carried >> by" would seem better > [NCW] SureŠwill do. > > >> >> 4.2.1: EAP-FAST and EAP-TTLS could do with references on >> first use. (Same later for other methods, e.g. TEAP in >> 4.2.3.) > > [NCW] They are already referenced in Section 1; would you like us > To repeat them in this section as well? Ah you're right. No, ignore me here too. >> 4.2.2: What'd it mean to creat a DoS against aspects of >> an assessment? I don't get that. > > [NCW] One example would be to insert a PT-EAP message to > tell a NEA Server that the endpoint is totally infected. > This could cause the device to be blocked from accessing > a critical resource, which would be a denial of service. Good example thanks. >> 4.2.2: 1st para, malformed octets don't really seem like >> message fabrication. > [NCW] Would it be better to change it to the example above? I think it would yes. >> 4.2.2: last sentence - something wrong here, you can't >> say that unless you have an MTI outer EAP method that >> does guarantee that or else they all do, but do they >> all? > > [NCW] If the EAP tunnel method meets the requirements in section 5, > it prevents undetected insertion of PT-EAP messages into a > properly authorized exchange. All of the EAP tunnel methods > described in section 4.3 meet those requirements. However, > it would be inappropriate to make one of them MTI for PT-EAP > because none of them is yet specified in a Standards Track RFC. Sure. Maybe a forward pointer to section 5 would help. (I mean it might help with reviewers, probably not that big a deal for later readers of the RFC.) >> 4.2.3: last sentence - is this missing a 2119 REQUIRED? > > [NCW] Some reviewers objected to putting RFC 2119 text into a Security > Considerations section. Therefore, we put all of the RFC 2119 > requirements on EAP tunnel methods in section 5. Whatever. I agree some people say that kind of thing. They are wrong. But fair enough. Better to s/required/needed/ if you're taking that approach since REQUIRED is a 2119 keyword (and 2119 doesn't really mandate upper case). >> >> 4.2.4: "encrypted and hashed" is pretty imprecise. > [NCW] How about we split the sentence into: > "After the cryptographic authentication by the EAP tunnel method, > the session can be protected cryptographically to provide confidentiality > and source authenticity. Such protection prevents undetected > modification that could create a denial of service situation." Nice. >> 4.3: I think if the use of TLS is significant then you >> need a reference to 5246. Maybe also 5280 but that could >> be implied by TLS. > [NCW] We do have a reference to RFC 5246. In fact, it's Normative. > TLS does permit PGP certificates to be used so it seems > wrong for us to reference RFC 5280. Fair enough. >> 4.3: Is the parenthetic "using TLVs" text here stuff that >> ought go away? I think it probably is. > [NCW] SureŠwill do. > >> >> section 6: the "MUST NOT observe" here seems like nonsense >> and nothing to do with 2119. > [NCW] SureŠwill do. > >> >> 7.1: is "PT-EAP Versions" a top-level registry or part of >> something else? I think you can answer this by saying >> what URL you think would be good for accessing this >> registry. > [NCW] It's Top levee registry. Might be good to say, or provide the URL you'd like to help IANA get it right without having to ask. Cheers, S. >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea > > > From jsalowey@cisco.com Wed Nov 28 10:23:38 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 AD69521F8471 for ; Wed, 28 Nov 2012 10:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 b0A1SotE90US for ; Wed, 28 Nov 2012 10:23:37 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A918A21F8472 for ; Wed, 28 Nov 2012 10:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4324; q=dns/txt; s=iport; t=1354127015; x=1355336615; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CNlOv67/VjuR4UCyc8kr9tSAwG4u+pD1u6SNZ/U/SqI=; b=DYfNJESBcSaI7W6t8arBh3c3nMuzJoo1EcCNIvn7nw4i3V3Jhi2AU1Ed 4AVc4bPQNBnr00OZqs5OlUG9ce4i7a9+qIhDyeNpZodanl1SZVhk2i1HA Kmc+OwBRC3JvK0vIWvVRSKrXL8PvCESx1Th51/FjsGPYELfsF5OIpl9w7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN1VtlCtJV2d/2dsb2JhbABFwBcWc4IeAQEBAwEBAQE3NAsFCwIBCBgKFBAnCyUCBA4FCIgBBgy/DYw/g2BhA5cdjyiCcIIh X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147240421" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 28 Nov 2012 18:23:33 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qASINXSD004648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 18:23:33 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.22]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 12:23:32 -0600 From: "Joseph Salowey (jsalowey)" To: Stephen Farrell Thread-Topic: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for IESG Evaluation) Thread-Index: AQHNzZV4n6USaIBocE2XM0Cl3YFB4Q== Date: Wed, 28 Nov 2012 18:23:32 +0000 Message-ID: References: <50B49A61.4000209@cs.tcd.ie> In-Reply-To: <50B49A61.4000209@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.147] Content-Type: text/plain; charset="us-ascii" Content-ID: <9D10417903949E49A7FE04300BA046A4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nea@ietf.org" Subject: Re: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for IESG Evaluation) 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 Nov 2012 18:23:38 -0000 The TEAP work in EMU is progressing well. I think it is realistic for the = document to go to the IESG before the next IETF. I think participation fro= m the NEA working group would even help accelerate the progress. I think = that previously that working group was concerned that the tunnel method wor= k would lag too far behind the PT-EAP method when making the choice to not = specify an MTI. =20 So I think 3) would be the best option, one might be OK if it is acceptable= to the IESG. =20 If a few folks on the NEA list could commit to doing a review of the TEAP d= ocument that would help mode things along. I believe its in the the best in= terest of the NEA group to review the document at this point to make sure t= hat it will meet your needs. The latest revision is available here: http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-04 Let me know if you can review. =20 Thanks, Joe=20 On Nov 27, 2012, at 2:48 AM, Stephen Farrell wrote: >=20 > Hi Nancy, >=20 > Thanks for that. Just splitting out the one non-nit thing, I'll > respond to the rest in a bit. >=20 > On 11/27/2012 03:51 AM, Nancy Cam-Winget (ncamwing) wrote: >=20 >>=20 >> On 11/18/12 6:45 PM, "Stephen Farrell" wrote= : >>=20 >=20 >>> questions I'd like answered before IETF LC: >>>=20 >>> 1) Doesn't the non-existence of a standards-track EAP outer >>> method that meets the needs of NEA (section 5, 2nd para) >>> mean that this draft ought stay in the RFC editor queue >>> until TEAP is done, and that TEAP ought be MTI for PT-EAP? >>> (Which could be easily done if the wg wanted it.) >>> If the wg's answer to is "no, its ok now", then I'm >>> confused, since you seem to require a standards track EAP >>> outer method that does not exist. Wouldn't that imply that >>> this protocol cannot be implemented as currently specified >>> and wouldn't that be a bad outcome for the IETF? >>=20 >> [NCW] The NEA WG discussed this at length and agreed that the spec >> should not wait for TEAP to be standardized. There was consensus >> that the already industry established/used tunnel methods, e.g. EAP-FAST= , >> EAP-TTLS and PEAP met the requirements in section 5 of PT-EAP; while >> these are not standardized by the IETF, several of them are documented >> in the IETF as informational RFCs. Further consensus indicated that the >> group both, did not want to wait for TEAP's standardization and that the= re >> would be some benefit if using the NEA protocols with the already existi= ng >> tunnel methods. >=20 > Ok, good to have this recently documented. >=20 > I guess the issue is that that plan leaves PT-EAP not really > conforming with BCP 61 (the one that says you MUST almost always > have strong security as MTI). [1] I'm sure that'll be a topic > for discussion during IESG evaluation, so best if we're explicit > about it now so we can point at this thread for the IESG. > (Apologies for rehashing the WG discussion, but I reckon > it'll be useful for the IESG.) >=20 > I reckon the following options exist in principle. >=20 > 1) Process PT-EAP as-is and have the discussion about BCP61 > with the IESG. I guess the WG argument here is in section 5 > of the document where it says that the outer EAP method > MUST do what's needed and points at TEAP. >=20 > 2) Pick one of the existing EAP methods and make that MTI. > We can handle the downref in the IETF LC, so that's not > an issue, if there's an existing method that would work for > the WG. The draft could also say that we expect folks to > migrate to a standards-track method in future. >=20 > 3) The WG could change its mind and decide to wait on TEAP > if the situation has moved on since this was discussed before. >=20 > The draft takes approach #1, so unless you (the WG) want to > change your mind I'm ok with progressing this on that basis, > but we may need to have the discussion with the IESG. >=20 > So, no response is needed to this, unless folks want to > plump for #2 or #3 or something else. >=20 > Thanks, > S. >=20 > [1] http://tools.ietf.org/html/bcp61 >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From ncamwing@cisco.com Wed Nov 28 10:43:54 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 D4EFC21F8201 for ; Wed, 28 Nov 2012 10:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.766 X-Spam-Level: X-Spam-Status: No, score=-9.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 XR0FQ+pweszS for ; Wed, 28 Nov 2012 10:43:53 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5DE21F8616 for ; Wed, 28 Nov 2012 10:43:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4747; q=dns/txt; s=iport; t=1354128232; x=1355337832; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5ZyWIIvGErSiwGVGvp2ME4TCPQW9rpkqrDFw5DJkzUg=; b=QBXfqnIRkP/PQuEo2T1/7B/oOPHHNK2SHXFf7AUqRKHBf7Msi6lPqHN3 L2m+DU3WlEx1K+2Zz5pYNKQTa8CVvfbbC2ezXZPWakaPyi/NGZhL1aBMi WHa343Yyc3XVr5FxeFNZsNEqL8Mu7YP+lhzESERIGjRG+1kcj3qz/G3qK 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAChbtlCtJV2Z/2dsb2JhbABFwCIWc4IeAQEBBAEBAWsLEgEIGApLCyUCBAENBQiICAy/EYw/g2BhA5cdjyiCcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147205777" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 28 Nov 2012 18:43:42 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qASIhfdg012560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 Nov 2012 18:43:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.109]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 12:43:41 -0600 From: "Nancy Cam-Winget (ncamwing)" To: "Joseph Salowey (jsalowey)" , Stephen Farrell Thread-Topic: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for IESG Evaluation) Thread-Index: AQHNzZhJ+tBo6mM0AESLI/OYJVejQg== Date: Wed, 28 Nov 2012 18:43:41 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.154.12.155] Content-Type: text/plain; charset="Windows-1252" Content-ID: <2DF571B7BC70EC4EA5EC29CC264B4C4B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nea@ietf.org" Subject: Re: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for IESG Evaluation) 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 Nov 2012 18:43:54 -0000 I agree with Joe; with the timing now, TEAP is very close to completion and may complete at the same time as PT-EAP so Option #3 would be the best option at this time. =8Awould also be good to get TEAP review from NEA participants! Thanks, Nancy. On 11/28/12 10:23 AM, "Joseph Salowey (jsalowey)" wrote: >The TEAP work in EMU is progressing well. I think it is realistic for >the document to go to the IESG before the next IETF. I think >participation from the NEA working group would even help accelerate the >progress. I think that previously that working group was concerned that >the tunnel method work would lag too far behind the PT-EAP method when >making the choice to not specify an MTI. > >So I think 3) would be the best option, one might be OK if it is >acceptable to the IESG. > >If a few folks on the NEA list could commit to doing a review of the TEAP >document that would help mode things along. I believe its in the the best >interest of the NEA group to review the document at this point to make >sure that it will meet your needs. The latest revision is available here: > >http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-04 > >Let me know if you can review. > >Thanks, > >Joe=20 > > > > >On Nov 27, 2012, at 2:48 AM, Stephen Farrell wrote: > >>=20 >> Hi Nancy, >>=20 >> Thanks for that. Just splitting out the one non-nit thing, I'll >> respond to the rest in a bit. >>=20 >> On 11/27/2012 03:51 AM, Nancy Cam-Winget (ncamwing) wrote: >>=20 >>>=20 >>> On 11/18/12 6:45 PM, "Stephen Farrell" >>>wrote: >>>=20 >>=20 >>>> questions I'd like answered before IETF LC: >>>>=20 >>>> 1) Doesn't the non-existence of a standards-track EAP outer >>>> method that meets the needs of NEA (section 5, 2nd para) >>>> mean that this draft ought stay in the RFC editor queue >>>> until TEAP is done, and that TEAP ought be MTI for PT-EAP? >>>> (Which could be easily done if the wg wanted it.) >>>> If the wg's answer to is "no, its ok now", then I'm >>>> confused, since you seem to require a standards track EAP >>>> outer method that does not exist. Wouldn't that imply that >>>> this protocol cannot be implemented as currently specified >>>> and wouldn't that be a bad outcome for the IETF? >>>=20 >>> [NCW] The NEA WG discussed this at length and agreed that the spec >>> should not wait for TEAP to be standardized. There was consensus >>> that the already industry established/used tunnel methods, e.g. >>>EAP-FAST, >>> EAP-TTLS and PEAP met the requirements in section 5 of PT-EAP; while >>> these are not standardized by the IETF, several of them are documented >>> in the IETF as informational RFCs. Further consensus indicated that the >>> group both, did not want to wait for TEAP's standardization and that >>>there >>> would be some benefit if using the NEA protocols with the already >>>existing >>> tunnel methods. >>=20 >> Ok, good to have this recently documented. >>=20 >> I guess the issue is that that plan leaves PT-EAP not really >> conforming with BCP 61 (the one that says you MUST almost always >> have strong security as MTI). [1] I'm sure that'll be a topic >> for discussion during IESG evaluation, so best if we're explicit >> about it now so we can point at this thread for the IESG. >> (Apologies for rehashing the WG discussion, but I reckon >> it'll be useful for the IESG.) >>=20 >> I reckon the following options exist in principle. >>=20 >> 1) Process PT-EAP as-is and have the discussion about BCP61 >> with the IESG. I guess the WG argument here is in section 5 >> of the document where it says that the outer EAP method >> MUST do what's needed and points at TEAP. >>=20 >> 2) Pick one of the existing EAP methods and make that MTI. >> We can handle the downref in the IETF LC, so that's not >> an issue, if there's an existing method that would work for >> the WG. The draft could also say that we expect folks to >> migrate to a standards-track method in future. >>=20 >> 3) The WG could change its mind and decide to wait on TEAP >> if the situation has moved on since this was discussed before. >>=20 >> The draft takes approach #1, so unless you (the WG) want to >> change your mind I'm ok with progressing this on that basis, >> but we may need to have the discussion with the IESG. >>=20 >> So, no response is needed to this, unless folks want to >> plump for #2 or #3 or something else. >>=20 >> Thanks, >> S. >>=20 >> [1] http://tools.ietf.org/html/bcp61 >>=20 >>=20 >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea > From shanna@juniper.net Thu Nov 29 06:54:01 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 AEA1F21F8A99 for ; Thu, 29 Nov 2012 06:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.467 X-Spam-Level: X-Spam-Status: No, score=-103.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132, 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 bMuBDxDxWIBM for ; Thu, 29 Nov 2012 06:54:00 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4763E21F8A9B for ; Thu, 29 Nov 2012 06:53:37 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKULd26OnPbKuJxATdR8N2YhgkFXAvW/IY@postini.com; Thu, 29 Nov 2012 06:53:41 PST 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; Thu, 29 Nov 2012 06:51:29 -0800 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 29 Nov 2012 06:51:29 -0800 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.181) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 29 Nov 2012 06:54:13 -0800 Received: from mail216-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE014.bigfish.com (10.43.70.64) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Nov 2012 14:51:28 +0000 Received: from mail216-ch1 (localhost [127.0.0.1]) by mail216-ch1-R.bigfish.com (Postfix) with ESMTP id D6E5C180424 for ; Thu, 29 Nov 2012 14:51:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -30 X-BigFish: PS-30(z551bizbb2dI98dI9371I542M1432I1418I4015Izz1de0h1202h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1155h) Received: from mail216-ch1 (localhost.localdomain [127.0.0.1]) by mail216-ch1 (MessageSwitch) id 1354200669456043_7638; Thu, 29 Nov 2012 14:51:09 +0000 (UTC) Received: from CH1EHSMHS032.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail216-ch1.bigfish.com (Postfix) with ESMTP id 6C018203C4; Thu, 29 Nov 2012 14:51:09 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by CH1EHSMHS032.bigfish.com (10.43.70.32) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Nov 2012 14:51:06 +0000 Received: from SN2PRD0510MB372.namprd05.prod.outlook.com ([169.254.12.35]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0239.002; Thu, 29 Nov 2012 14:50:58 +0000 From: Stephen Hanna To: "Nancy Cam-Winget (ncamwing)" , "Joseph Salowey (jsalowey)" , Stephen Farrell Thread-Topic: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for IESG Evaluation) Thread-Index: AQHNzZhhsnei9OTL50S1PGpcGqf86pf/sS2w Date: Thu, 29 Nov 2012 14:50:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%CS.TCD.IE$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "nea@ietf.org" Subject: Re: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for IESG Evaluation) 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, 29 Nov 2012 14:54:01 -0000 Certainly there's a lot to be said for having a complete top-to-bottom set of MTI protocols. I'm OK with option #3 if we can request early allocation of the EAP Method type for PT-EAP from IANA and if we permit using other EAP tunnel methods with PT-EAP. This should allow people to start implementing and testing PT-EAP now, while the EMU WG is putting the final touches on TEAP. There are several people who would like to get started on implementing PT-EAP and gaining operational experience with it. That's a good thing and we should encourage it! Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Nancy Cam-Winget (ncamwing) > Sent: Wednesday, November 28, 2012 1:44 PM > To: Joseph Salowey (jsalowey); Stephen Farrell > Cc: nea@ietf.org > Subject: Re: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for > IESG Evaluation) >=20 > I agree with Joe; with the timing now, TEAP is very close to completion > and may complete at the same time as PT-EAP so > Option #3 would be the best option at this time. >=20 > =A9would also be good to get TEAP review from NEA participants! >=20 > Thanks, Nancy. >=20 > On 11/28/12 10:23 AM, "Joseph Salowey (jsalowey)" > wrote: >=20 > >The TEAP work in EMU is progressing well. I think it is realistic for > >the document to go to the IESG before the next IETF. I think > >participation from the NEA working group would even help accelerate > the > >progress. I think that previously that working group was concerned > that > >the tunnel method work would lag too far behind the PT-EAP method when > >making the choice to not specify an MTI. > > > >So I think 3) would be the best option, one might be OK if it is > >acceptable to the IESG. > > > >If a few folks on the NEA list could commit to doing a review of the > TEAP > >document that would help mode things along. I believe its in the the > best > >interest of the NEA group to review the document at this point to make > >sure that it will meet your needs. The latest revision is available > here: > > > >http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-04 > > > >Let me know if you can review. > > > >Thanks, > > > >Joe > > > > > > > > > >On Nov 27, 2012, at 2:48 AM, Stephen Farrell wrote: > > > >> > >> Hi Nancy, > >> > >> Thanks for that. Just splitting out the one non-nit thing, I'll > >> respond to the rest in a bit. > >> > >> On 11/27/2012 03:51 AM, Nancy Cam-Winget (ncamwing) wrote: > >> > >>> > >>> On 11/18/12 6:45 PM, "Stephen Farrell" > >>>wrote: > >>> > >> > >>>> questions I'd like answered before IETF LC: > >>>> > >>>> 1) Doesn't the non-existence of a standards-track EAP outer > >>>> method that meets the needs of NEA (section 5, 2nd para) > >>>> mean that this draft ought stay in the RFC editor queue > >>>> until TEAP is done, and that TEAP ought be MTI for PT-EAP? > >>>> (Which could be easily done if the wg wanted it.) > >>>> If the wg's answer to is "no, its ok now", then I'm > >>>> confused, since you seem to require a standards track EAP > >>>> outer method that does not exist. Wouldn't that imply that > >>>> this protocol cannot be implemented as currently specified > >>>> and wouldn't that be a bad outcome for the IETF? > >>> > >>> [NCW] The NEA WG discussed this at length and agreed that the spec > >>> should not wait for TEAP to be standardized. There was consensus > >>> that the already industry established/used tunnel methods, e.g. > >>>EAP-FAST, > >>> EAP-TTLS and PEAP met the requirements in section 5 of PT-EAP; > while > >>> these are not standardized by the IETF, several of them are > documented > >>> in the IETF as informational RFCs. Further consensus indicated that > the > >>> group both, did not want to wait for TEAP's standardization and > that > >>>there > >>> would be some benefit if using the NEA protocols with the already > >>>existing > >>> tunnel methods. > >> > >> Ok, good to have this recently documented. > >> > >> I guess the issue is that that plan leaves PT-EAP not really > >> conforming with BCP 61 (the one that says you MUST almost always > >> have strong security as MTI). [1] I'm sure that'll be a topic > >> for discussion during IESG evaluation, so best if we're explicit > >> about it now so we can point at this thread for the IESG. > >> (Apologies for rehashing the WG discussion, but I reckon > >> it'll be useful for the IESG.) > >> > >> I reckon the following options exist in principle. > >> > >> 1) Process PT-EAP as-is and have the discussion about BCP61 > >> with the IESG. I guess the WG argument here is in section 5 > >> of the document where it says that the outer EAP method > >> MUST do what's needed and points at TEAP. > >> > >> 2) Pick one of the existing EAP methods and make that MTI. > >> We can handle the downref in the IETF LC, so that's not > >> an issue, if there's an existing method that would work for > >> the WG. The draft could also say that we expect folks to > >> migrate to a standards-track method in future. > >> > >> 3) The WG could change its mind and decide to wait on TEAP > >> if the situation has moved on since this was discussed before. > >> > >> The draft takes approach #1, so unless you (the WG) want to > >> change your mind I'm ok with progressing this on that basis, > >> but we may need to have the discussion with the IESG. > >> > >> So, no response is needed to this, unless folks want to > >> plump for #2 or #3 or something else. > >> > >> Thanks, > >> S. > >> > >> [1] http://tools.ietf.org/html/bcp61 > >> > >> > >> _______________________________________________ > >> Nea mailing list > >> Nea@ietf.org > >> https://www.ietf.org/mailman/listinfo/nea > > >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From stephen.farrell@cs.tcd.ie Thu Nov 29 07:12: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 2E51D21F888D for ; Thu, 29 Nov 2012 07:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6leq43Qi3fz for ; Thu, 29 Nov 2012 07:12:02 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 08CAE21F88C2 for ; Thu, 29 Nov 2012 07:12:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5E518BE6D; Thu, 29 Nov 2012 15:11:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0oWU4XGDK7e; Thu, 29 Nov 2012 15:11:36 +0000 (GMT) Received: from [IPv6:2001:770:10:203:1185:5f2c:eb87:a222] (unknown [IPv6:2001:770:10:203:1185:5f2c:eb87:a222]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 33D41BE66; Thu, 29 Nov 2012 15:11:36 +0000 (GMT) Message-ID: <50B77B28.9030409@cs.tcd.ie> Date: Thu, 29 Nov 2012 15:11:36 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Stephen Hanna References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: "nea@ietf.org" Subject: Re: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for IESG Evaluation) 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, 29 Nov 2012 15:12:03 -0000 On 11/29/2012 02:50 PM, Stephen Hanna wrote: > Certainly there's a lot to be said for having a complete top-to-bottom > set of MTI protocols. I'm OK with option #3 if we can request early > allocation of the EAP Method type for PT-EAP from IANA and if we permit > using other EAP tunnel methods with PT-EAP. This should allow people to > start implementing and testing PT-EAP now, while the EMU WG is putting > the final touches on TEAP. There are several people who would like to > get started on implementing PT-EAP and gaining operational experience > with it. That's a good thing and we should encourage it! Great. If the WG are ok with that I think it'd be a better outcome. On the registration, I see [1] EAP methods 1-191 are specification required and 191-255 are "standards action." I'm not sure what's the intent there, but presumably we can ask the DE to ok it and get an early registration since PT-EAP is a WG document. Maybe Joe can clarify? (And Joe, are you the designated expert as EMU chair?) Cheers, S. [1] http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3 > > Thanks, > > Steve > >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of >> Nancy Cam-Winget (ncamwing) >> Sent: Wednesday, November 28, 2012 1:44 PM >> To: Joseph Salowey (jsalowey); Stephen Farrell >> Cc: nea@ietf.org >> Subject: Re: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for >> IESG Evaluation) >> >> I agree with Joe; with the timing now, TEAP is very close to completion >> and may complete at the same time as PT-EAP so >> Option #3 would be the best option at this time. >> >> Šwould also be good to get TEAP review from NEA participants! >> >> Thanks, Nancy. >> >> On 11/28/12 10:23 AM, "Joseph Salowey (jsalowey)" >> wrote: >> >>> The TEAP work in EMU is progressing well. I think it is realistic for >>> the document to go to the IESG before the next IETF. I think >>> participation from the NEA working group would even help accelerate >> the >>> progress. I think that previously that working group was concerned >> that >>> the tunnel method work would lag too far behind the PT-EAP method when >>> making the choice to not specify an MTI. >>> >>> So I think 3) would be the best option, one might be OK if it is >>> acceptable to the IESG. >>> >>> If a few folks on the NEA list could commit to doing a review of the >> TEAP >>> document that would help mode things along. I believe its in the the >> best >>> interest of the NEA group to review the document at this point to make >>> sure that it will meet your needs. The latest revision is available >> here: >>> >>> http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-04 >>> >>> Let me know if you can review. >>> >>> Thanks, >>> >>> Joe >>> >>> >>> >>> >>> On Nov 27, 2012, at 2:48 AM, Stephen Farrell wrote: >>> >>>> >>>> Hi Nancy, >>>> >>>> Thanks for that. Just splitting out the one non-nit thing, I'll >>>> respond to the rest in a bit. >>>> >>>> On 11/27/2012 03:51 AM, Nancy Cam-Winget (ncamwing) wrote: >>>> >>>>> >>>>> On 11/18/12 6:45 PM, "Stephen Farrell" >>>>> wrote: >>>>> >>>> >>>>>> questions I'd like answered before IETF LC: >>>>>> >>>>>> 1) Doesn't the non-existence of a standards-track EAP outer >>>>>> method that meets the needs of NEA (section 5, 2nd para) >>>>>> mean that this draft ought stay in the RFC editor queue >>>>>> until TEAP is done, and that TEAP ought be MTI for PT-EAP? >>>>>> (Which could be easily done if the wg wanted it.) >>>>>> If the wg's answer to is "no, its ok now", then I'm >>>>>> confused, since you seem to require a standards track EAP >>>>>> outer method that does not exist. Wouldn't that imply that >>>>>> this protocol cannot be implemented as currently specified >>>>>> and wouldn't that be a bad outcome for the IETF? >>>>> >>>>> [NCW] The NEA WG discussed this at length and agreed that the spec >>>>> should not wait for TEAP to be standardized. There was consensus >>>>> that the already industry established/used tunnel methods, e.g. >>>>> EAP-FAST, >>>>> EAP-TTLS and PEAP met the requirements in section 5 of PT-EAP; >> while >>>>> these are not standardized by the IETF, several of them are >> documented >>>>> in the IETF as informational RFCs. Further consensus indicated that >> the >>>>> group both, did not want to wait for TEAP's standardization and >> that >>>>> there >>>>> would be some benefit if using the NEA protocols with the already >>>>> existing >>>>> tunnel methods. >>>> >>>> Ok, good to have this recently documented. >>>> >>>> I guess the issue is that that plan leaves PT-EAP not really >>>> conforming with BCP 61 (the one that says you MUST almost always >>>> have strong security as MTI). [1] I'm sure that'll be a topic >>>> for discussion during IESG evaluation, so best if we're explicit >>>> about it now so we can point at this thread for the IESG. >>>> (Apologies for rehashing the WG discussion, but I reckon >>>> it'll be useful for the IESG.) >>>> >>>> I reckon the following options exist in principle. >>>> >>>> 1) Process PT-EAP as-is and have the discussion about BCP61 >>>> with the IESG. I guess the WG argument here is in section 5 >>>> of the document where it says that the outer EAP method >>>> MUST do what's needed and points at TEAP. >>>> >>>> 2) Pick one of the existing EAP methods and make that MTI. >>>> We can handle the downref in the IETF LC, so that's not >>>> an issue, if there's an existing method that would work for >>>> the WG. The draft could also say that we expect folks to >>>> migrate to a standards-track method in future. >>>> >>>> 3) The WG could change its mind and decide to wait on TEAP >>>> if the situation has moved on since this was discussed before. >>>> >>>> The draft takes approach #1, so unless you (the WG) want to >>>> change your mind I'm ok with progressing this on that basis, >>>> but we may need to have the discussion with the IESG. >>>> >>>> So, no response is needed to this, unless folks want to >>>> plump for #2 or #3 or something else. >>>> >>>> Thanks, >>>> S. >>>> >>>> [1] http://tools.ietf.org/html/bcp61 >>>> >>>> >>>> _______________________________________________ >>>> Nea mailing list >>>> Nea@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nea >>> >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea > > > > From jsalowey@cisco.com Thu Nov 29 09:44:10 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 6606721F8AFC for ; Thu, 29 Nov 2012 09:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 KW4AzYGmr8OG for ; Thu, 29 Nov 2012 09:44:09 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3AC21F8B40 for ; Thu, 29 Nov 2012 09:44:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7331; q=dns/txt; s=iport; t=1354211049; x=1355420649; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ejKYeZlkzBMqOKiaHPRMK853+5VMv2jIfVueC1iGeGI=; b=gACnYh6gl0iJoo26lzM+NKdukMyeVYimDr9M9TFgmdqocT/v5Vukahc+ NrAxzFwr8DTDnvPrgPnnC2J/yzLAlmVQVv7gEVHyFlsh/VAM2Asqz/Dhl q3MjLqcYoHyY73HI9QJ12DptfzRFmZG1Bc9AVvQeJMGbFLikmmXORxEHb s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACqet1CtJV2Y/2dsb2JhbABEwBcWc4IeAQEBAwEBAQFoAQILBQcEAgEIEQQBAQEKHQcnCxQJCAIEDgUIAYgBBgy/JYxAg2BhA5cdjyiCcoIh X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="147634353" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 29 Nov 2012 17:44:07 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qATHi7ta029124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Nov 2012 17:44:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.22]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 11:44:07 -0600 From: "Joseph Salowey (jsalowey)" To: Stephen Farrell Thread-Topic: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for IESG Evaluation) Thread-Index: AQHNzkFwWoIo4BvnyU+0cqP6HMxaFZgBT7gAgAAqmIA= Date: Thu, 29 Nov 2012 17:44:06 +0000 Message-ID: References: <50B77B28.9030409@cs.tcd.ie> In-Reply-To: <50B77B28.9030409@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.147] Content-Type: text/plain; charset="Windows-1252" Content-ID: <56674F31DB0AE04182E53FEF8417F9C6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nea@ietf.org" Subject: Re: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for IESG Evaluation) 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, 29 Nov 2012 17:44:10 -0000 On Nov 29, 2012, at 7:11 AM, Stephen Farrell wrote: >=20 >=20 > On 11/29/2012 02:50 PM, Stephen Hanna wrote: >> Certainly there's a lot to be said for having a complete top-to-bottom >> set of MTI protocols. I'm OK with option #3 if we can request early >> allocation of the EAP Method type for PT-EAP from IANA and if we permit >> using other EAP tunnel methods with PT-EAP. This should allow people to >> start implementing and testing PT-EAP now, while the EMU WG is putting >> the final touches on TEAP. There are several people who would like to >> get started on implementing PT-EAP and gaining operational experience >> with it. That's a good thing and we should encourage it! >=20 > Great. If the WG are ok with that I think it'd be a better > outcome. >=20 > On the registration, I see [1] EAP methods 1-191 are specification > required and 191-255 are "standards action." I'm not sure what's > the intent there, but presumably we can ask the DE to ok it and > get an early registration since PT-EAP is a WG document. Maybe > Joe can clarify? (And Joe, are you the designated expert as EMU > chair?) >=20 [Joe] I think I used to be, I haven't seen requests recently for EAP-method= s that have not gone through the IETF process so I'm not sure if I am still= the designated expert or not. I don't see a problem with early registrati= on. =20 > Cheers, > S. >=20 >=20 >=20 > [1] > http://www.iana.org/assignments/eap-numbers/eap-numbers.xml#eap-numbers-3 >=20 >>=20 >> Thanks, >>=20 >> Steve >>=20 >>> -----Original Message----- >>> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of >>> Nancy Cam-Winget (ncamwing) >>> Sent: Wednesday, November 28, 2012 1:44 PM >>> To: Joseph Salowey (jsalowey); Stephen Farrell >>> Cc: nea@ietf.org >>> Subject: Re: [Nea] MTI EAP outer method (was: Re: PT-EAP I-D Ready for >>> IESG Evaluation) >>>=20 >>> I agree with Joe; with the timing now, TEAP is very close to completion >>> and may complete at the same time as PT-EAP so >>> Option #3 would be the best option at this time. >>>=20 >>> =8Awould also be good to get TEAP review from NEA participants! >>>=20 >>> Thanks, Nancy. >>>=20 >>> On 11/28/12 10:23 AM, "Joseph Salowey (jsalowey)" >>> wrote: >>>=20 >>>> The TEAP work in EMU is progressing well. I think it is realistic for >>>> the document to go to the IESG before the next IETF. I think >>>> participation from the NEA working group would even help accelerate >>> the >>>> progress. I think that previously that working group was concerned >>> that >>>> the tunnel method work would lag too far behind the PT-EAP method when >>>> making the choice to not specify an MTI. >>>>=20 >>>> So I think 3) would be the best option, one might be OK if it is >>>> acceptable to the IESG. >>>>=20 >>>> If a few folks on the NEA list could commit to doing a review of the >>> TEAP >>>> document that would help mode things along. I believe its in the the >>> best >>>> interest of the NEA group to review the document at this point to make >>>> sure that it will meet your needs. The latest revision is available >>> here: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-04 >>>>=20 >>>> Let me know if you can review. >>>>=20 >>>> Thanks, >>>>=20 >>>> Joe >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Nov 27, 2012, at 2:48 AM, Stephen Farrell wrote: >>>>=20 >>>>>=20 >>>>> Hi Nancy, >>>>>=20 >>>>> Thanks for that. Just splitting out the one non-nit thing, I'll >>>>> respond to the rest in a bit. >>>>>=20 >>>>> On 11/27/2012 03:51 AM, Nancy Cam-Winget (ncamwing) wrote: >>>>>=20 >>>>>>=20 >>>>>> On 11/18/12 6:45 PM, "Stephen Farrell" >>>>>> wrote: >>>>>>=20 >>>>>=20 >>>>>>> questions I'd like answered before IETF LC: >>>>>>>=20 >>>>>>> 1) Doesn't the non-existence of a standards-track EAP outer >>>>>>> method that meets the needs of NEA (section 5, 2nd para) >>>>>>> mean that this draft ought stay in the RFC editor queue >>>>>>> until TEAP is done, and that TEAP ought be MTI for PT-EAP? >>>>>>> (Which could be easily done if the wg wanted it.) >>>>>>> If the wg's answer to is "no, its ok now", then I'm >>>>>>> confused, since you seem to require a standards track EAP >>>>>>> outer method that does not exist. Wouldn't that imply that >>>>>>> this protocol cannot be implemented as currently specified >>>>>>> and wouldn't that be a bad outcome for the IETF? >>>>>>=20 >>>>>> [NCW] The NEA WG discussed this at length and agreed that the spec >>>>>> should not wait for TEAP to be standardized. There was consensus >>>>>> that the already industry established/used tunnel methods, e.g. >>>>>> EAP-FAST, >>>>>> EAP-TTLS and PEAP met the requirements in section 5 of PT-EAP; >>> while >>>>>> these are not standardized by the IETF, several of them are >>> documented >>>>>> in the IETF as informational RFCs. Further consensus indicated that >>> the >>>>>> group both, did not want to wait for TEAP's standardization and >>> that >>>>>> there >>>>>> would be some benefit if using the NEA protocols with the already >>>>>> existing >>>>>> tunnel methods. >>>>>=20 >>>>> Ok, good to have this recently documented. >>>>>=20 >>>>> I guess the issue is that that plan leaves PT-EAP not really >>>>> conforming with BCP 61 (the one that says you MUST almost always >>>>> have strong security as MTI). [1] I'm sure that'll be a topic >>>>> for discussion during IESG evaluation, so best if we're explicit >>>>> about it now so we can point at this thread for the IESG. >>>>> (Apologies for rehashing the WG discussion, but I reckon >>>>> it'll be useful for the IESG.) >>>>>=20 >>>>> I reckon the following options exist in principle. >>>>>=20 >>>>> 1) Process PT-EAP as-is and have the discussion about BCP61 >>>>> with the IESG. I guess the WG argument here is in section 5 >>>>> of the document where it says that the outer EAP method >>>>> MUST do what's needed and points at TEAP. >>>>>=20 >>>>> 2) Pick one of the existing EAP methods and make that MTI. >>>>> We can handle the downref in the IETF LC, so that's not >>>>> an issue, if there's an existing method that would work for >>>>> the WG. The draft could also say that we expect folks to >>>>> migrate to a standards-track method in future. >>>>>=20 >>>>> 3) The WG could change its mind and decide to wait on TEAP >>>>> if the situation has moved on since this was discussed before. >>>>>=20 >>>>> The draft takes approach #1, so unless you (the WG) want to >>>>> change your mind I'm ok with progressing this on that basis, >>>>> but we may need to have the discussion with the IESG. >>>>>=20 >>>>> So, no response is needed to this, unless folks want to >>>>> plump for #2 or #3 or something else. >>>>>=20 >>>>> Thanks, >>>>> S. >>>>>=20 >>>>> [1] http://tools.ietf.org/html/bcp61 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Nea mailing list >>>>> Nea@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nea >>>>=20 >>>=20 >>> _______________________________________________ >>> Nea mailing list >>> Nea@ietf.org >>> https://www.ietf.org/mailman/listinfo/nea >>=20 >>=20 >>=20 >>=20