From sethomso@cisco.com Mon Apr 11 18:16:34 2011 Return-Path: X-Original-To: nea@ietfc.amsl.com Delivered-To: nea@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4419DE06B6 for ; Mon, 11 Apr 2011 18:16:34 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE2Xw4tyhfY4 for ; Mon, 11 Apr 2011 18:16:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfc.amsl.com (Postfix) with ESMTP id 5C677E0613 for ; Mon, 11 Apr 2011 18:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=1367; q=dns/txt; s=iport; t=1302570992; x=1303780592; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=BQxW1/bLmDdd0zOJCm8cSiQlIpQVH0SLJICd4xzu080=; b=gBBR6qwhh7rnyKNOL00uYCZ0VxpccKBDDzt/Ed2yTBsPFv2CKHm7X/kI 5bIMKOQeyW1kywwxvTgS4cZ3faNVst7tmpIs5cySS8FR5S297hOZGPHDU o58stM+Ms2lAzpCv1jjZBEt1gpzVfUosv1lsJEJDfeA3azM4BB619SMTr E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8HAHKno02tJXG//2dsb2JhbACZBY0cd6UsnGOFbgSFW4tu X-IronPort-AV: E=Sophos;i="4.64,193,1301875200"; d="scan'208";a="679365896" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by sj-iport-6.cisco.com with ESMTP; 12 Apr 2011 01:16:26 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3C1GQuR027710 for ; Tue, 12 Apr 2011 01:16:26 GMT Received: from xmb-rcd-105.cisco.com ([72.163.62.147]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 20:16:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2011 20:16:25 -0500 Message-ID: <043901FAFD488D44ACC9CCED00470BDC04B29BEB@XMB-RCD-105.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Verifying consensus on next steps re TLS/TCP-based PT Thread-Index: Acv4rz3tc1/J9hl0R9y+k9A9ge1wCg== From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 12 Apr 2011 01:16:26.0175 (UTC) FILETIME=[3E8044F0:01CBF8AF] Subject: [Nea] Verifying consensus on next steps re TLS/TCP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 01:16:34 -0000 At IETF80, there was a discussion on next steps regarding the individual submissions for a TLS/TCP-based PT, and an EAP-based PT. Specifically, there are 2 proposals for a TLS/TCP-based transport documented in the following I-Ds: http://www.ietf.org/internet-drafts/draft-sangster-nea-pt-tls-02.txt=20 http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt At the meeting, there was unanimous consensus to merge the TLS/TCP proposals in the above I-Ds as follows: - Support client authentication using the SASL framework - Support vendor extensions - Support error handling The authors of the above I-Ds have agreed to work on a joint WG submission. The chairs would like to verify this consensus on the mailing=20 list. Please review the proposal and respond by Monday, 5pm PT on=20 Apr 18. Indicate in your response whether you support the changes.=20 If you support the changes, a one word response ("Support") is=20 sufficient. If not, please explain your concerns and suggest how=20 they could be resolved. Thanks Susan ---------------------------- Note: No consensus has yet been reached on the EAP-based proposals, in particular, whether to use an EAP method or EAP-TLV for carrying posture information. The next step is to document the strengths and weaknesses of these 2 approaches to help make a decision. From stefan.winter@restena.lu Mon Apr 11 23:08:21 2011 Return-Path: X-Original-To: nea@ietfc.amsl.com Delivered-To: nea@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 74555E072D for ; Mon, 11 Apr 2011 23:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3DWepT2NV8X for ; Mon, 11 Apr 2011 23:08:20 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfc.amsl.com (Postfix) with ESMTP id A455BE071B for ; Mon, 11 Apr 2011 23:08:20 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 96489106CB for ; Tue, 12 Apr 2011 08:08:19 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7B62010691 for ; Tue, 12 Apr 2011 08:08:19 +0200 (CEST) Message-ID: <4DA3EC53.60302@restena.lu> Date: Tue, 12 Apr 2011 08:08:19 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: nea@ietf.org References: <043901FAFD488D44ACC9CCED00470BDC04B29BEB@XMB-RCD-105.cisco.com> In-Reply-To: <043901FAFD488D44ACC9CCED00470BDC04B29BEB@XMB-RCD-105.cisco.com> X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig58F8624E9B7E70CE42E5470C" X-Virus-Scanned: ClamAV Subject: Re: [Nea] Verifying consensus on next steps re TLS/TCP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 06:08:21 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig58F8624E9B7E70CE42E5470C Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support Am 12.04.2011 03:16, schrieb Susan Thomson (sethomso): > At IETF80, there was a discussion on next steps regarding the individua= l > submissions for a TLS/TCP-based PT, and an EAP-based PT. > > Specifically, there are 2 proposals for a TLS/TCP-based transport > documented in the following I-Ds: > http://www.ietf.org/internet-drafts/draft-sangster-nea-pt-tls-02.txt=20 > http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt > > At the meeting, there was unanimous consensus to merge the TLS/TCP > proposals in the above I-Ds as follows: > - Support client authentication using the SASL framework > - Support vendor extensions > - Support error handling > > The authors of the above I-Ds have agreed to work on a joint WG > submission. > > The chairs would like to verify this consensus on the mailing=20 > list. Please review the proposal and respond by Monday, 5pm PT on=20 > Apr 18. Indicate in your response whether you support the changes.=20 > If you support the changes, a one word response ("Support") is=20 > sufficient. If not, please explain your concerns and suggest how=20 > they could be resolved. > > Thanks > Susan > ---------------------------- > > Note: No consensus has yet been reached on the EAP-based proposals, in > particular, whether to use an EAP method or EAP-TLV for carrying postur= e > information. The next step is to document the strengths and weaknesses > of these 2 approaches to help make a decision. > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --------------enig58F8624E9B7E70CE42E5470C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2j7FMACgkQ+jm90f8eFWa5BACdHMafT1blyfwWK5qhk8aFU9/8 pzcAnAt5JckgbejcEv8q9DKHe1e8ZVor =8EF2 -----END PGP SIGNATURE----- --------------enig58F8624E9B7E70CE42E5470C-- From shanna@juniper.net Mon Apr 11 23:14:12 2011 Return-Path: X-Original-To: nea@ietfc.amsl.com Delivered-To: nea@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2D2D0E0740 for ; Mon, 11 Apr 2011 23:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8JcsXqvOtIb for ; Mon, 11 Apr 2011 23:14:11 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfc.amsl.com (Postfix) with ESMTP id F36E5E073E for ; Mon, 11 Apr 2011 23:14:10 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKTaPtsk0aCIuOVzndoJq1bdeyYZRHFbqd@postini.com; Mon, 11 Apr 2011 23:14:11 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 11 Apr 2011 23:11:58 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 12 Apr 2011 02:13:49 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Tue, 12 Apr 2011 02:13:48 -0400 Thread-Topic: Verifying consensus on next steps re TLS/TCP-based PT Thread-Index: Acv4rz3tc1/J9hl0R9y+k9A9ge1wCgAKYZXg Message-ID: References: <043901FAFD488D44ACC9CCED00470BDC04B29BEB@XMB-RCD-105.cisco.com> In-Reply-To: <043901FAFD488D44ACC9CCED00470BDC04B29BEB@XMB-RCD-105.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Nea] Verifying consensus on next steps re TLS/TCP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 06:14:12 -0000 Support > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Susan Thomson (sethomso) > Sent: Monday, April 11, 2011 9:16 PM > To: nea@ietf.org > Subject: [Nea] Verifying consensus on next steps re TLS/TCP-based PT >=20 > At IETF80, there was a discussion on next steps regarding the > individual > submissions for a TLS/TCP-based PT, and an EAP-based PT. >=20 > Specifically, there are 2 proposals for a TLS/TCP-based transport > documented in the following I-Ds: > http://www.ietf.org/internet-drafts/draft-sangster-nea-pt-tls-02.txt > http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt >=20 > At the meeting, there was unanimous consensus to merge the TLS/TCP > proposals in the above I-Ds as follows: > - Support client authentication using the SASL framework > - Support vendor extensions > - Support error handling >=20 > The authors of the above I-Ds have agreed to work on a joint WG > submission. >=20 > The chairs would like to verify this consensus on the mailing > list. Please review the proposal and respond by Monday, 5pm PT on > Apr 18. Indicate in your response whether you support the changes. > If you support the changes, a one word response ("Support") is > sufficient. If not, please explain your concerns and suggest how > they could be resolved. >=20 > Thanks > Susan > ---------------------------- >=20 > Note: No consensus has yet been reached on the EAP-based proposals, in > particular, whether to use an EAP method or EAP-TLV for carrying > posture > information. The next step is to document the strengths and weaknesses > of these 2 approaches to help make a decision. > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From latze@angry-red-pla.net Tue Apr 12 01:45:39 2011 Return-Path: X-Original-To: nea@ietfc.amsl.com Delivered-To: nea@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 479DDE06B6 for ; Tue, 12 Apr 2011 01:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LtHVkZoJWML for ; Tue, 12 Apr 2011 01:45:38 -0700 (PDT) Received: from thuvia.angry-red-pla.net (thuvia.angry-red-pla.net [83.169.33.217]) by ietfc.amsl.com (Postfix) with ESMTP id 786D2E06B2 for ; Tue, 12 Apr 2011 01:45:38 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=thuvia.angry-red-pla.net) by thuvia.angry-red-pla.net with esmtp (Exim 4.69) (envelope-from ) id 1Q9ZE8-0005Fu-3o for nea@ietf.org; Tue, 12 Apr 2011 10:45:37 +0200 Received: from 193.5.238.18 (SquirrelMail authenticated user latze) by thuvia.angry-red-pla.net with HTTP; Tue, 12 Apr 2011 10:45:36 +0200 (CEST) Message-ID: <486bf848fa84a7340368018914aa4afa.squirrel@thuvia.angry-red-pla.net> In-Reply-To: <043901FAFD488D44ACC9CCED00470BDC04B29BEB@XMB-RCD-105.cisco.com> References: <043901FAFD488D44ACC9CCED00470BDC04B29BEB@XMB-RCD-105.cisco.com> Date: Tue, 12 Apr 2011 10:45:36 +0200 (CEST) From: latze@angry-red-pla.net To: nea@ietf.org User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: [Nea] Verifying consensus on next steps re TLS/TCP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 08:45:39 -0000 Support > At IETF80, there was a discussion on next steps regarding the individual > submissions for a TLS/TCP-based PT, and an EAP-based PT. > > Specifically, there are 2 proposals for a TLS/TCP-based transport > documented in the following I-Ds: > http://www.ietf.org/internet-drafts/draft-sangster-nea-pt-tls-02.txt > http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt > > At the meeting, there was unanimous consensus to merge the TLS/TCP > proposals in the above I-Ds as follows: > - Support client authentication using the SASL framework > - Support vendor extensions > - Support error handling > > The authors of the above I-Ds have agreed to work on a joint WG > submission. > > The chairs would like to verify this consensus on the mailing > list. Please review the proposal and respond by Monday, 5pm PT on > Apr 18. Indicate in your response whether you support the changes. > If you support the changes, a one word response ("Support") is > sufficient. If not, please explain your concerns and suggest how > they could be resolved. > > Thanks > Susan > ---------------------------- > > Note: No consensus has yet been reached on the EAP-based proposals, in > particular, whether to use an EAP method or EAP-TLV for carrying posture > information. The next step is to document the strengths and weaknesses > of these 2 approaches to help make a decision. > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > From Kent_Landfield@McAfee.com Tue Apr 12 05:15:03 2011 Return-Path: X-Original-To: nea@ietfc.amsl.com Delivered-To: nea@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8462AE0699 for ; Tue, 12 Apr 2011 05:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fEJXYLfdvJA for ; Tue, 12 Apr 2011 05:15:02 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfc.amsl.com (Postfix) with ESMTP id 3C809E06BD for ; Tue, 12 Apr 2011 05:15:01 -0700 (PDT) Received: from (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp (TLS: TLSv1/SSLv3,128bits,AES128-SHA) id 2af1_38e3_7cd44236_64fe_11e0_9b03_00219b929abd; Tue, 12 Apr 2011 12:15:00 +0000 Received: from AMERDALEXMB1.corp.nai.org ([fe80::387d:3d79:ad3b:b517]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Tue, 12 Apr 2011 07:13:15 -0500 From: To: Date: Tue, 12 Apr 2011 07:13:19 -0500 Thread-Topic: [Nea] Verifying consensus on next steps re TLS/TCP-based PT Thread-Index: Acv5Cv9yyesVEushTE2jll/6pbp//Q== Message-ID: <5591C0FC-8021-41EB-8601-0B916CA6AA5A@McAfee.com> References: <043901FAFD488D44ACC9CCED00470BDC04B29BEB@XMB-RCD-105.cisco.com> In-Reply-To: <043901FAFD488D44ACC9CCED00470BDC04B29BEB@XMB-RCD-105.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: nea@ietf.org Subject: Re: [Nea] Verifying consensus on next steps re TLS/TCP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 12:15:03 -0000 Support Kent Landfield McAfee Labs Kent_Landfield@McAfee.com +1.817.637.8026=20 On Apr 11, 2011, at 8:16 PM, "Susan Thomson (sethomso)" wrote: > At IETF80, there was a discussion on next steps regarding the individual > submissions for a TLS/TCP-based PT, and an EAP-based PT. >=20 > Specifically, there are 2 proposals for a TLS/TCP-based transport > documented in the following I-Ds: > http://www.ietf.org/internet-drafts/draft-sangster-nea-pt-tls-02.txt=20 > http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt >=20 > At the meeting, there was unanimous consensus to merge the TLS/TCP > proposals in the above I-Ds as follows: > - Support client authentication using the SASL framework > - Support vendor extensions > - Support error handling >=20 > The authors of the above I-Ds have agreed to work on a joint WG > submission. >=20 > The chairs would like to verify this consensus on the mailing=20 > list. Please review the proposal and respond by Monday, 5pm PT on=20 > Apr 18. Indicate in your response whether you support the changes.=20 > If you support the changes, a one word response ("Support") is=20 > sufficient. If not, please explain your concerns and suggest how=20 > they could be resolved. >=20 > Thanks > Susan > ---------------------------- >=20 > Note: No consensus has yet been reached on the EAP-based proposals, in > particular, whether to use an EAP method or EAP-TLV for carrying posture > information. The next step is to document the strengths and weaknesses > of these 2 approaches to help make a decision. > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From blueroofmusic@gmail.com Tue Apr 12 11:06:07 2011 Return-Path: X-Original-To: nea@ietfc.amsl.com Delivered-To: nea@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C3A30E0822 for ; Tue, 12 Apr 2011 11:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7-R0n+z5i9R for ; Tue, 12 Apr 2011 11:06:06 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfc.amsl.com (Postfix) with ESMTP id 9A899E072E for ; Tue, 12 Apr 2011 11:06:06 -0700 (PDT) Received: by fxm15 with SMTP id 15so5165970fxm.31 for ; Tue, 12 Apr 2011 11:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HgXnL89QOWaRgVdSNJNI46wl0ZE8RRq5dwAMYFhSWyA=; b=iuy8wlFsoxLon2/Uq4RMdzp1VEdDD4PH/oPuZxrdHj7VsI9zbJlc3AnE06KhpuNbwF 6ZGG5OBgea0ZocKaYYoPu81OkjfIyktJ8huZZnjF6Pehpow12JD3J9oCloP+DDGq9UcO jlvvcPhmhGXgRZ95ckGqUCJm9Z7oyNYgyhJHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r4pMFdMZ1+vI5+DNqRt+iEU/xv8d++9iMURLAQr3EZtNvkJd3HAaviSKRHsZ9Yzgh3 HWpleIrM31eQwz7k6SDlGpNpIjGswU0pI1tDCZcIzqZ6+uR4+/4dtIqRFs45r4r+P1Pv 83bI5/eCPJ8yKPgIJnmRK73yfTINRv7NTYAes= MIME-Version: 1.0 Received: by 10.223.99.153 with SMTP id u25mr109601fan.112.1302631081419; Tue, 12 Apr 2011 10:58:01 -0700 (PDT) Received: by 10.223.114.77 with HTTP; Tue, 12 Apr 2011 10:58:01 -0700 (PDT) In-Reply-To: <043901FAFD488D44ACC9CCED00470BDC04B29BEB@XMB-RCD-105.cisco.com> References: <043901FAFD488D44ACC9CCED00470BDC04B29BEB@XMB-RCD-105.cisco.com> Date: Tue, 12 Apr 2011 13:58:01 -0400 Message-ID: From: Ira McDonald To: "Susan Thomson (sethomso)" , Ira McDonald Content-Type: multipart/alternative; boundary=0015174beb46e1a60004a0bc6e99 Cc: nea@ietf.org Subject: Re: [Nea] Verifying consensus on next steps re TLS/TCP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 18:06:07 -0000 --0015174beb46e1a60004a0bc6e99 Content-Type: text/plain; charset=ISO-8859-1 Support Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Hardcopy WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music/High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto:blueroofmusic@gmail.com Christmas through April: 579 Park Place Saline, MI 48176 734-944-0094 May to Christmas: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Apr 11, 2011 at 9:16 PM, Susan Thomson (sethomso) < sethomso@cisco.com> wrote: > At IETF80, there was a discussion on next steps regarding the individual > submissions for a TLS/TCP-based PT, and an EAP-based PT. > > Specifically, there are 2 proposals for a TLS/TCP-based transport > documented in the following I-Ds: > http://www.ietf.org/internet-drafts/draft-sangster-nea-pt-tls-02.txt > http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt > > At the meeting, there was unanimous consensus to merge the TLS/TCP > proposals in the above I-Ds as follows: > - Support client authentication using the SASL framework > - Support vendor extensions > - Support error handling > > The authors of the above I-Ds have agreed to work on a joint WG > submission. > > The chairs would like to verify this consensus on the mailing > list. Please review the proposal and respond by Monday, 5pm PT on > Apr 18. Indicate in your response whether you support the changes. > If you support the changes, a one word response ("Support") is > sufficient. If not, please explain your concerns and suggest how > they could be resolved. > > Thanks > Susan > ---------------------------- > > Note: No consensus has yet been reached on the EAP-based proposals, in > particular, whether to use an EAP method or EAP-TLV for carrying posture > information. The next step is to document the strengths and weaknesses > of these 2 approaches to help make a decision. > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > --0015174beb46e1a60004a0bc6e99 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Support

Ira McDonald (Musician / Software Architect)Chair - Linux Foundation Open Printing WG
Co-Chair - IEEE-ISTO PWG IPP= WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Pri= nter MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic<= /a>
http://sites.google.com/site/highnorth= inc
mailto:blueroo= fmusic@gmail.com
Christmas through April:
=A0 579 Park Place=A0 S= aline, MI=A0 48176
=A0 734-944-0094
May to Christmas:
=A0 PO Box 2= 21=A0 Grand Marais, MI 49839
=A0 906-494-2434



On Mon, Apr 11, 2011 at 9:16 PM, Susan T= homson (sethomso) <sethomso@cisco.com> wrote:
At IETF80, there was a discussion on next steps regarding the individual submissions for a TLS/TCP-based PT, and an EAP-based PT.

Specifically, there are 2 proposals for a TLS/TCP-based transport
documented in the following I-Ds:
http://www.ietf.org/internet-drafts/draft-sangster-= nea-pt-tls-02.txt
http://www.ietf.org/internet-drafts/draft-cam-winget= -eap-tlv-03.txt

At the meeting, there was unanimous consensus to merge the TLS/TCP
proposals in the above I-Ds as follows:
- Support client authentication using the SASL framework
- Support vendor extensions
- Support error handling

The authors of the above I-Ds have agreed to work on a joint WG
submission.

The chairs would like to verify this consensus on the mailing
list. Please review the proposal and respond by Monday, 5pm PT on
Apr 18. Indicate in your response whether you support the changes.
If you support the changes, a one word response ("Support") is sufficient. If not, please explain your concerns and suggest how
they could be resolved.

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

Note: No consensus has yet been reached on the EAP-based proposals, in
particular, whether to use an EAP method or EAP-TLV for carrying posture information. The next step is to document the strengths and weaknesses
of these 2 approaches to help make a decision.
_______________________________________________
Nea mailing list
Nea@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/nea

--0015174beb46e1a60004a0bc6e99-- From sethomso@cisco.com Thu Apr 28 14:47:04 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5902E073E for ; Thu, 28 Apr 2011 14:47:04 -0700 (PDT) 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=[AWL=0.000, 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 HhkbCSyhyG2R for ; Thu, 28 Apr 2011 14:47:03 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by ietfa.amsl.com (Postfix) with ESMTP id C1914E06A6 for ; Thu, 28 Apr 2011 14:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=1864; q=dns/txt; s=iport; t=1304027223; x=1305236823; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=yqTifNGGKil+ZHB0IozquOgMs9l9EKTfm2F4IbCI+3c=; b=ERb3a2XrlsPOIx3IQtxGmJD5OcMlSnIuk6VT9gKHPMFb3kvP84e0FLaC aOAzdbWePDb7QNB0t77gr2CPw27ErZGlqHYI78AZaf9MQUduupFz7rtBE fbaZjWcnqllP4VZjaplHQsXp16XdUXKgGngvyOoz5H8auJK853ZeBq+sk 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUBAFTfuU2tJV2c/2dsb2JhbACYCj+NOXenboEdnRKFdgSGCYxwigw X-IronPort-AV: E=Sophos;i="4.64,283,1301875200"; d="scan'208";a="231756309" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 28 Apr 2011 21:47:03 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p3SLl2eh011303 for ; Thu, 28 Apr 2011 21:47:03 GMT Received: from xmb-rcd-105.cisco.com ([72.163.62.147]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 16:47:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Apr 2011 16:46:59 -0500 Message-ID: <043901FAFD488D44ACC9CCED00470BDC04DAAA68@XMB-RCD-105.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Verifying consensus on next steps re TLS/TCP-based PT Thread-Index: Acv4rz3tc1/J9hl0R9y+k9A9ge1wCgLtQvEg From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 28 Apr 2011 21:47:02.0366 (UTC) FILETIME=[CEE8E7E0:01CC05ED] Subject: Re: [Nea] Verifying consensus on next steps re TLS/TCP-based PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 21:47:04 -0000 I counted 5 responses to the consensus check question on next steps re the L3-based PT protocols. All responded in the affirmative. I declare consensus to merge the TLS/TCP-based protocols into one submission as described. The co-authors can go ahead with publishing a merged proposal. Thanks Susan -----Original Message----- From: Susan Thomson (sethomso)=20 Sent: Monday, April 11, 2011 9:16 PM To: nea@ietf.org Subject: Verifying consensus on next steps re TLS/TCP-based PT At IETF80, there was a discussion on next steps regarding the individual submissions for a TLS/TCP-based PT, and an EAP-based PT. Specifically, there are 2 proposals for a TLS/TCP-based transport documented in the following I-Ds: http://www.ietf.org/internet-drafts/draft-sangster-nea-pt-tls-02.txt=20 http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt At the meeting, there was unanimous consensus to merge the TLS/TCP proposals in the above I-Ds as follows: - Support client authentication using the SASL framework - Support vendor extensions - Support error handling The authors of the above I-Ds have agreed to work on a joint WG submission. The chairs would like to verify this consensus on the mailing=20 list. Please review the proposal and respond by Monday, 5pm PT on=20 Apr 18. Indicate in your response whether you support the changes.=20 If you support the changes, a one word response ("Support") is=20 sufficient. If not, please explain your concerns and suggest how=20 they could be resolved. Thanks Susan ---------------------------- Note: No consensus has yet been reached on the EAP-based proposals, in particular, whether to use an EAP method or EAP-TLV for carrying posture information. The next step is to document the strengths and weaknesses of these 2 approaches to help make a decision. From sethomso@cisco.com Thu Apr 28 14:47:32 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71D0E06A6 for ; Thu, 28 Apr 2011 14:47:32 -0700 (PDT) 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=[AWL=0.000, 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 k-8Bg8dYNmtL for ; Thu, 28 Apr 2011 14:47:31 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id 30839E0762 for ; Thu, 28 Apr 2011 14:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=13138; q=dns/txt; s=iport; t=1304027251; x=1305236851; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=70f9z4tPOt46peCTre9UpFiOZ3KaWUk/gT7VvNHswVI=; b=WCDvM4MnHMVbo9HX2bv8/Bhj+nEtoadLeh/3QxfaUXO1xjwBgxM8XMlU trNVpzKC9ICQrpdIUwMHwCMxPkau2f8hB9xubVePJTPFGo+be3rGM3rq2 Z2qQ2kAyYkdbnAONVWgp4c+QS3AMv1xntNXW/U2453xRrJzFXJmnVmujP 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAXguU2tJXHB/2dsb2JhbACmAXenb4EdnRKCfxOCZASGCYxwigw X-IronPort-AV: E=Sophos;i="4.64,283,1301875200"; d="scan'208";a="231327115" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rtp-iport-1.cisco.com with ESMTP; 28 Apr 2011 21:47:30 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p3SLlTLs028968 for ; Thu, 28 Apr 2011 21:47:30 GMT Received: from xmb-rcd-105.cisco.com ([72.163.62.147]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 16:47:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: AlwG BEVF CMjP DyzJ ENRZ EfrY FVEU FfiO FhZF GDba GIIv IQLX IdqM Jkgj KYIG LVmS; 1; bgBlAGEAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {6CCE0967-DD15-4BC6-A3E6-1CDF08AC9A0B}; cwBlAHQAaABvAG0AcwBvAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Thu, 28 Apr 2011 21:47:23 GMT; RAByAGEAZgB0ACAAbQBpAG4AdQB0AGUAcwAgAGYAcgBvAG0AIABJAEUAVABGADgAMAA= MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {6CCE0967-DD15-4BC6-A3E6-1CDF08AC9A0B} Content-class: urn:content-classes:message Date: Thu, 28 Apr 2011 16:47:23 -0500 Message-ID: <043901FAFD488D44ACC9CCED00470BDC04DAAA69@XMB-RCD-105.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes from IETF80 Thread-Index: AcwF7duq/pZGngDFQsCPCLQLIzXKgQ== From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 28 Apr 2011 21:47:29.0608 (UTC) FILETIME=[DF25B480:01CC05ED] Subject: [Nea] Draft minutes from IETF80 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, 28 Apr 2011 21:47:32 -0000 Draft minutes from IETF 80 below. Please send any corrections to me by Wed, May 4 at 5pm PT. Thanks Susan ----------------------------------- These notes do not attempt to duplicate the content of the slides.=20 Instead, they summarize the material presented, and focus on=20 comments and discussion. Agenda =3D=3D=3D=3D=3D=3D Date: Tuesday, Mar 29, 2011 Time: 1300-1500=20 WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 1300 Administrivia Blue Sheets Jabber & Minute scribes Agenda bashing 1305 WG Status 1310 NEA Reference Model 1315 Discuss PT Candidates, Decide On Path Forward http://www.ietf.org/internet-drafts/draft-sangster-nea-pt-tls-02.txt http://www.ietf.org/internet-drafts/draft-cam-winget-eap-tlv-03.txt http://www.ietf.org/internet-drafts/draft-hanna-nea-pt-eap-01.txt 1455 Milestones 1500 Adjourn WG Status =3D=3D=3D=3D=3D=3D=3D=3D=3D Susan Thomson reviewed WG status. PT I-Ds have been updated to take=20 into account the counter-measure to the NEA Asokan attack. There are 3=20 individual submissions for transport protocols - one proposes TLS=20 based transport, one EAP based and one has models for both. The main=20 objective of this meeting is to review the PT proposals, and decide=20 which approaches should be adopted by the WG. =20 NEA Reference Model =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Steve Hanna reviewed the NEA reference model for the benefit of=20 those new to the WG. PT-TLS Review =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Paul Sangster reviewed the PT-TLS proposal which has been defined in=20 TCG.=20 PT-TLS consists of 3 phases: - TLS Handshake - Version Negotiation - Optional Client authentication (not discussed) - NEA Assessments The message format is based on that of PA-TNC and PB-TNC to support=20 code reuse. It supports vendor extensions, and a message-ID to help=20 with error handling. Steve added that TNC supports legacy protocols, and thus the vendor ID=20 is important for backwards compatibility. Kevin Fall asked a question about the NEA requirement to support UDP.=20 Paul clarified that the requirement was to support TCP or UDP, and=20 that the proposal met the requirement. EAP-TLV and PT-TCP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nancy Winget described both the EAP and TCP proposals together since=20 they are in the same document. The proposed EAP approach is to use TLV/AVP structures to carry PB-TNC=20 messages in deployed EAP tunnel methods.=20 The proposed L3-based approach is to use a TLV to carry NEA in TLS=20 over TCP, and use the SASL framework for client authentication. PT-EAP =3D=3D=3D=3D=3D=3D Steve described the PT-EAP proposal from TCG. In this proposal, EAP is encapsulated in an EAP tunnel method such as=20 PEAP, EAP-TTLS and EAP-FAST. No change is required to the tunnel=20 methods. This method supports chaining with other EAP methods, and can be=20 proxed via RADIUS, and supports fragmentation when needed. Steve listed 9 PT-EAP implementations. Paul added that there is an OpenSEA implementation of PA and PB=20 protocols running over PT-EAP. Also, that there is an implementation=20 of PT-TLS. Kevin asked a question about which fields in the PT-EAP header were=20 EAP-specific, versus specific to PT-EAP.=20 Steve clarified that all fields were specific to PT-EAP. Stefan Winter asked whether either of the EAP proposals would support=20 EAP-TLS, not just EAP tunnel methods. Steve explained that EAP-TLS does not allow for the opportunity to=20 send data. Nancy further explained that if you were to add data to the EAP-TLS=20 method, you would be effectively creating a new EAP tunnel method. Mauricio Sanchez asked whether there was a requirement to support TCG=20 standards. Steve answered that there is no requirement in RFC 5209,but it is=20 desirable for compatibility. Paul added that there was a requirement to select an open standard. Mauricio asked whether this meant that the spec could then not be=20 changed. Steve said that the spec can be changed; the point was to take=20 advantage of implementation experience. Susan said that the next item on the agenda was to evaluate the=20 proposals. The L3 proposals would be compared first followed by the=20 EAP-based proposals. There is a recommended path forward for the L3=20 proposals, and at the end of the discussion period there will be a=20 consensus check. Evaluation of PT-TLS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Paul described the pros of the PT-TLS approach. Besides being a TCG=20 standard, the advantages are that PT-TLS supported versioning, vendor=20 extensions and error handling.=20 Concerns were expressed that the alternate proposal, PT-TCP, did not=20 satisfy the selection requirement to prefer open standards. Also, that=20 versioning and error handling are not supported. Paul then compared the message formats. Mauricio asked whether the differences in the message formats were=20 just nits. Susan said that there is a recommendation to move forward on a=20 converged proposal and therefore no need to dwell on differences in=20 message formats. Enaluation of PT-TCP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nancy said that the main difference between the two proposals is that=20 the client authentication is supported through SASL. Consensus Check on Merging PT-TLS and PT-TCP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Susan said that the recommendation was to merge the two proposals as=20 follows: - Client authentication using SASL framework - Support version handling - Support error handling Susan asked the ADs whether the document could be a -00 WG document=20 when it was published, or whether it needed to be another individual=20 submission. Tim Polk said that assuming consensus was reached on the mailing list,=20 that it could be published as a WG document. Stephen Farrell agreed on the assumption that there would be joint=20 authors on the document. Kevin asked whether support for error handling meant support for=20 Message-ID field or whether other approaches might be acceptable. Paul said that other approaches were possible. Susan asked for a show of hands for merging the documents as=20 described. There was consensus to do so. The consensus will be checked=20 on the mailing list. PT-EAP Evaluation =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Steve said that there is no agreement on the EAP-based proposals yet. Steve said that the advantages of PT-EAP are that it works with any=20 tunnel method and EAP transport, supports RADIUS proxy, is a TCG=20 standard with deployment experience and security review by several=20 parties, and supports fragmentation.=20 Steve said that the concern with the alternate proposal, EAP-TLV, is=20 that it does not meet the selection criteria of being an open=20 standard, does not support fragmentation, is hard to proxy, and only=20 has one implementation. Joe Salowey argued that proxying in either approach needs work. The=20 main difference between the two is that, in PT-EAP, EAP is an existing=20 attribute. Steve said that any AAA server has the capability for proxying an=20 inner method inside a tunnel method. Joe said that this is not universal behavior, and it is also=20 questionable behavior from a security point of view. Steve agreed that the transport of the posture needs to be secured. Mauricio asked whether proxying is a requirement or a nice to have. Steve said proxying was nice to have. Steve then compared the two proposals pointing out the main difference=20 in the approach is whether an EAP method is used to carry posture=20 information, or whether a TLV or AVP is used. Joe clarified that the reason that there are two encapsulations=20 defined for carrying NEA in the EAP-TLV proposal is because the EAP=20 tunnel methods use different encapsulations.=20 Nancy argued that the main difference is whether to use an EAP method=20 or a TLV. Existing tunnel methods provide a means to pass non- authentication-related data. Posture can be carried in a TLV because=20 it is not authentication and no keys need to be generated.=20 Stefan asked whether PT-EAP requires EAP chaining support from the=20 tunnel method, and whether EAP-TLV treates the posture as an=20 attribute. Steve says yes. Steve said that he agreed with Nancy that the main difference is=20 whether to use an EAP method or TLV, and that otherwise there was not=20 much difference when it came to header formats.=20 He said that there was one other important difference that should be=20 considered though: open standards, implementation experience and=20 security reviews.=20 Susan asked whether the protocol analysis was done prior to or after=20 the change made to address the NEA Asokan attack. Steve said that the protocol has not been reviewed with the new=20 counter-measure in place. Kevin asked what the difference is between the original TCG proposal and the current proposal. Steve said that there had been WG consensus to use tls-unique=20 extractor data as the counter-measure to the NEA Asokan attack. Evaluation of EAP-TLV: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Nancy reiterated that the main difference is whether the posture data=20 is carried inside an EAP method or TLV.=20 She said a potential security concern of using an EAP method is that=20 it can be carried outside an EAP tunnel method in an unprotected,=20 standalone method.=20 Stephen Farrell asked what the implementation status of EAP-TLV is.=20 Nancy said that Cisco has implemented it, but chose to no longer=20 support it after an acquisition.=20 Consensus Check: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Susan asked the WG for a show of hands whether the WG favored adopting=20 the PT-EAP proposal, the EAP-TLV proposal or neither. There was a majority in favor of adopting the PT-EAP proposal, with a=20 minority in favor of the EAP-TLV proposal. One person indicated that=20 he was not in favor of making a decision at this time. Kevin Fall argued, that it seemed that with more time, it would be=20 possible to converge on a common proposal. Tim Polk argued that the decision need not be made today. Steve asked whether anybody had any suggestions about how the=20 difference could be resolved. One person said that it should be evaluated whether security issues=20 raised with the EAP method are a concern. Also, whether the size of=20 posture data that can be carried is a concern. Tim Polk said it might be useful to pull in other EAP experts to see=20 whether there are any other considerations that should be taken into=20 account that might make one a winner over the other. Joe said we should also verify whether EAP chaining works in tunneled=20 methods. Nancy asked about whether the EAP requirements document includes a=20 requirement for EAP chaining. Joe said that it does. From a spec point of view, existing tunnel=20 methods do support EAP chaining, but it is not known whether the=20 implementations do.=20 Joe said that running posture outside an EAP tunnel makes him nervous,=20 and that maybe better security considerations text would help. Kathy Moriarty mentioned that it is better to not leave the choice up=20 to the operator to make security decisions. Paul said that the D-H exchange in the original PT-EAP to defeat the=20 Asokan attack may still be useful. The reason he mentions this is that=20 this would only be an option with an EAP method. Joe argued that this could be done with a TLV-approach as well, and it=20 would be needed in both EAP and L3 transports. Also, the D-H approach=20 in the original approach only worked in the previous approach because=20 the EMA Agent was able to authenticate in the PA tunnel. Susan proposed that the next step be to identify the architectural=20 differences between the EAP-method approach versus the TLV approach=20 (not the specs themselves, but the 2 approaches only), and then bring=20 it back to the WG for a decision.=20 Stephen asked whether the mailing list would have the same opinion as=20 the WG. Susan said she thought yes as the question had been asked about a year=20 ago with the same results. Tim Polk suggested that once the differences are identified, the ADs=20 can also do some x-area review to get early feedback. Stephen Farrell said that it would be best if the approaches were=20 combined, and that both looked sound. Milestones: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Susan reviewed the new milestones. Meeting adjourned. =20