From shanna@juniper.net Mon Jun 6 13:20:45 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 35EA311E817D for ; Mon, 6 Jun 2011 13:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id od9aRI3pgzy1 for ; Mon, 6 Jun 2011 13:20:44 -0700 (PDT) Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id 70DB711E816B for ; Mon, 6 Jun 2011 13:20:40 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKTe02mDoFBNG+Jddp6ELkbtp9Wt2db0eP@postini.com; Mon, 06 Jun 2011 13:20:41 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 6 Jun 2011 13:18:30 -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; Mon, 6 Jun 2011 16:18:30 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Mon, 6 Jun 2011 16:18:29 -0400 Thread-Topic: Status of NEA PT work Thread-Index: AcwkXl2AR1dfxM9oRLeFYyF6O7e2vwAAzabwAAj11KA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Nea] Status of NEA PT work 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, 06 Jun 2011 20:20:45 -0000 I was asked to send out a status update on the NEA PT work. As noted in the minutes from the last NEA WG F2F, the authors of the two L3 PT proposals have agreed to work together on a joint specification. That document should be released as a NEA WG draft in the next week or so. As for the L2 PT proposals, it was agreed at the last NEA F2F that the best way to decide between an EAP method or TLVs for L2 PT is to have the proponents of the two approaches work together to describe the pros and cons of these two approaches, then bring that comparison back to the email list for consideration. This has been going on for the last month or so. The members of the small group working on the pros and cons list are Nancy Cam-Winget, Steve Hanna, Joe Salowey, and Paul Sangster (the authors of the various PT drafts). This group expects to send out an agreed-upon list of pros and cons later this week. Then the NEA WG list can decide how to proceed. So we're making good progress! We should be ready to review a solid L3 PT proposal in short order and also to decide on whether an EAP method or TLVs is the best approach. Thanks, Steve From shanna@juniper.net Thu Jun 9 10:05:31 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80B611E81CE for ; Thu, 9 Jun 2011 10:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KreBzD4lfScv for ; Thu, 9 Jun 2011 10:05:31 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id C4A1011E81CD for ; Thu, 9 Jun 2011 10:05:30 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTfD9Wp6sEzkTn33Y00l0ziMpvpWtJ6LH@postini.com; Thu, 09 Jun 2011 10:05:30 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 9 Jun 2011 10:03:54 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 9 Jun 2011 13:03:54 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Thu, 9 Jun 2011 13:03:52 -0400 Thread-Topic: Pros and cons of EAP and TLVs for L2 PT Thread-Index: AcwmxzWngKxgsxSdQCmkmLD+c6DQ5g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Nea] Pros and cons of EAP and TLVs for L2 PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 17:05:31 -0000 As I mentioned in my recent email to the NEA list, the PT draft editors have been working (as requested at the last NEA WG meeting) on a list of pros and cons for different approaches to the L2 PT protocol. This group has now agreed on a set of pros and cons: EAP for PT Pro: Can export keys (but no clear value at this time) Pro: Multiple Interoperable Independent Implementations Con: More likely to accidentally be used outside EAP tunnel TLVs for PT Pro: Can run in parallel with authentication Of course, these are just bullet points. They're quite short and don't capture all the nuances of the issues. Let's start up an email discussion on the NEA list where we can elaborate on these points and discuss them. In the end, I hope that we can reach rough consensus on what is the best approach. So let the discussion begin! Thanks, Steve From brford@cisco.com Thu Jun 9 13:33:15 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 DBB8D11E8213 for ; Thu, 9 Jun 2011 13:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 NzhEyqAZ4Wgh for ; Thu, 9 Jun 2011 13:33:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id EADF011E80E2 for ; Thu, 9 Jun 2011 13:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=brford@cisco.com; l=2153; q=dns/txt; s=iport; t=1307651594; x=1308861194; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=El0S5jkfHURu54j5fgklodmPuL1zB00kVQVAivutc90=; b=UH3jZOvdtBVnzNsTdp5bnn7OKRLX89P5f+sgbLNFJL1/s+o6a2ifV/0Y 47I3jAIDSSfJ4A9SWLLGzVw4XxBiL3lfiQx/QbLUMJaeZggQkMifnGSCY LUSGYDnluYwXdNleXqGR4qxEEfAUp2abxFfU2XmtBxp89PXCSMmdGPveD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGot8U2tJXG+/2dsb2JhbABTpkB3iHGgUIEfngmGIwSRKoRWixg X-IronPort-AV: E=Sophos;i="4.65,343,1304294400"; d="scan'208";a="462901619" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 09 Jun 2011 20:33:14 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p59KXECC003090 for ; Thu, 9 Jun 2011 20:33:14 GMT Received: from xmb-rcd-302.cisco.com ([72.163.63.17]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 15:33:14 -0500 Received: from 10.98.29.185 ([10.98.29.185]) by XMB-RCD-302.cisco.com ([72.163.63.17]) with Microsoft Exchange Server HTTP-DAV ; Thu, 9 Jun 2011 20:33:14 +0000 User-Agent: Microsoft-Entourage/12.29.0.110113 Date: Thu, 09 Jun 2011 16:33:07 -0400 From: brford To: NEA Message-ID: Thread-Topic: Pros and cons of EAP for L2 PT Thread-Index: Acwm5HCTVF2NkJeHOkONeSkwx9351A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 09 Jun 2011 20:33:14.0205 (UTC) FILETIME=[74DEA8D0:01CC26E4] Subject: [Nea] Pros and cons of EAP for L2 PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 20:33:16 -0000 In > PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods >> draft-hanna-nea-pt-eap-00.txt >> It says... > EAP-TNC is designed to operate as an inner EAP [10] method over an > EAP tunnel method that meets the Requirements for a Tunnel Based EAP > Method [17]. PT-EAP therefore can operate over a number of existing > access protocols that support EAP for authentication. Some examples > of such access protocols include 802.1X [7] for wired and wireless > networks and IKEv2 [15] for establishing VPNs over IP networks. Does that mean that the data gathered at an endpoint via some NEA client would be available to party that controls the 802.1x or IKEv2 exchange? Would that data only be available after a successful 802.1x auth or tunnel negotiation? On 6/9/11 3:00 PM, "nea-request@ietf.org" wrote: > Message: 1 > Date: Thu, 9 Jun 2011 13:03:52 -0400 > From: Stephen Hanna > To: "nea@ietf.org" > Subject: [Nea] Pros and cons of EAP and TLVs for L2 PT > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > As I mentioned in my recent email to the NEA list, the > PT draft editors have been working (as requested at the > last NEA WG meeting) on a list of pros and cons for > different approaches to the L2 PT protocol. This group > has now agreed on a set of pros and cons: > > EAP for PT > Pro: Can export keys (but no clear value at this time) > Pro: Multiple Interoperable Independent Implementations > Con: More likely to accidentally be used outside EAP tunnel > > TLVs for PT > Pro: Can run in parallel with authentication > > Of course, these are just bullet points. They're quite > short and don't capture all the nuances of the issues. > Let's start up an email discussion on the NEA list where > we can elaborate on these points and discuss them. In the > end, I hope that we can reach rough consensus on what is > the best approach. > > So let the discussion begin! > > Thanks, > > Steve > From shanna@juniper.net Thu Jun 9 14:21:51 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 A0808228005 for ; Thu, 9 Jun 2011 14:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bAzUmbxj46hw for ; Thu, 9 Jun 2011 14:21:50 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id CC1CD21F84D0 for ; Thu, 9 Jun 2011 14:21:49 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTfE5bYD4RPAiDvjf+fd61iyDf0aCAxFo@postini.com; Thu, 09 Jun 2011 14:21:50 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 9 Jun 2011 14:21:37 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 9 Jun 2011 17:21:37 -0400 From: Stephen Hanna To: brford , NEA Date: Thu, 9 Jun 2011 17:21:35 -0400 Thread-Topic: Pros and cons of EAP for L2 PT Thread-Index: Acwm5HCTVF2NkJeHOkONeSkwx9351AAAGR2A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Nea] Pros and cons of EAP for L2 PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2011 21:21:51 -0000 Good question. With both L2 PT proposals that we have received, data gathered at the endpoint is available in unprotected form to the EAP server that terminates the tunnel method. The EAP peer must authenticate the EAP server and determine that it is trusted to receive data about the endpoint's posture. However, this is not an unusual requirement. When using a tunnel method, EAP peers are generally expected to authenticate the EAP server and decide whether it's trustworthy before any data is sent over the tunnel method. You asked about whether "the party that controls the 802.1x or IKEv2 exchange" would have access to data on endpoint posture. That depends on the deployment environment and what you meant by those words. In an 802.1X environment, the authenticator (e.g. a wireless access point) generally would NOT have access to data on endpoint posture. That data would be conveyed in the encrypted, authenticated EAP tunnel method to the EAP server. None of this is different whether you use TLVs or an EAP method to carry the NEA exchange. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > brford > Sent: Thursday, June 09, 2011 4:33 PM > To: NEA > Subject: [Nea] Pros and cons of EAP for L2 PT >=20 >=20 > In > > PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods > >> draft-hanna-nea-pt-eap-00.txt > >> >=20 > It says... > > EAP-TNC is designed to operate as an inner EAP [10] method over an > > EAP tunnel method that meets the Requirements for a Tunnel Based > EAP > > Method [17]. PT-EAP therefore can operate over a number of > existing > > access protocols that support EAP for authentication. Some > examples > > of such access protocols include 802.1X [7] for wired and wireless > > networks and IKEv2 [15] for establishing VPNs over IP networks. >=20 > Does that mean that the data gathered at an endpoint via some NEA > client > would be available to party that controls the 802.1x or IKEv2 exchange? >=20 > Would that data only be available after a successful 802.1x auth or > tunnel > negotiation? >=20 > On 6/9/11 3:00 PM, "nea-request@ietf.org" wrote: >=20 > > Message: 1 > > Date: Thu, 9 Jun 2011 13:03:52 -0400 > > From: Stephen Hanna > > To: "nea@ietf.org" > > Subject: [Nea] Pros and cons of EAP and TLVs for L2 PT > > Message-ID: > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > As I mentioned in my recent email to the NEA list, the > > PT draft editors have been working (as requested at the > > last NEA WG meeting) on a list of pros and cons for > > different approaches to the L2 PT protocol. This group > > has now agreed on a set of pros and cons: > > > > EAP for PT > > Pro: Can export keys (but no clear value at this time) > > Pro: Multiple Interoperable Independent Implementations > > Con: More likely to accidentally be used outside EAP tunnel > > > > TLVs for PT > > Pro: Can run in parallel with authentication > > > > Of course, these are just bullet points. They're quite > > short and don't capture all the nuances of the issues. > > Let's start up an email discussion on the NEA list where > > we can elaborate on these points and discuss them. In the > > end, I hope that we can reach rough consensus on what is > > the best approach. > > > > So let the discussion begin! > > > > Thanks, > > > > Steve > > >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From andreas.steffen@strongswan.org Thu Jun 9 23:02:38 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA57D21F84C8 for ; Thu, 9 Jun 2011 23:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNqJGVZtrBtH for ; Thu, 9 Jun 2011 23:02:37 -0700 (PDT) Received: from strongswan.org (sitav-80024.hsr.ch [152.96.80.24]) by ietfa.amsl.com (Postfix) with ESMTP id 43CFB21F84D7 for ; Thu, 9 Jun 2011 23:02:36 -0700 (PDT) Received: from gprs61.swisscom-mobile.ch ([193.247.250.61] helo=[10.5.216.31]) by strongswan.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1QUunX-0007IX-Dc; Fri, 10 Jun 2011 08:02:23 +0200 Message-ID: <4DF1B361.4060805@strongswan.org> Date: Fri, 10 Jun 2011 08:02:09 +0200 From: Andreas Steffen Organization: strongSwan Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: nea@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Nea] Pros and cons of EAP for L2 PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 06:02:38 -0000 On 09.06.2011 23:21, Stephen Hanna wrote: > Good question. With both L2 PT proposals that we have > received, data gathered at the endpoint is available > in unprotected form to the EAP server that terminates > the tunnel method. The EAP peer must authenticate the > EAP server and determine that it is trusted to receive > data about the endpoint's posture. However, this is > not an unusual requirement. When using a tunnel method, > EAP peers are generally expected to authenticate the > EAP server and decide whether it's trustworthy before > any data is sent over the tunnel method. > > You asked about whether "the party that controls the > 802.1x or IKEv2 exchange" would have access to data > on endpoint posture. That depends on the deployment > environment and what you meant by those words. In an > 802.1X environment, the authenticator (e.g. a wireless > access point) generally would NOT have access to data > on endpoint posture. That data would be conveyed in > the encrypted, authenticated EAP tunnel method to > the EAP server. > The same holds with IKEv2. If a tunneled EAP method (e.g. EAP-TTLS or EAP-FAST) is used to encapsulate the PT protocol then the IKEv2 Policy Enforcement Point (i.e. the VPN gateway) does not have any access to the data). > None of this is different whether you use TLVs or > an EAP method to carry the NEA exchange. > > Thanks, > > Steve > Best regards Andreas >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of >> brford >> Sent: Thursday, June 09, 2011 4:33 PM >> To: NEA >> Subject: [Nea] Pros and cons of EAP for L2 PT >> >> >> In >>> PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel Methods >>>> draft-hanna-nea-pt-eap-00.txt >>>> >> >> It says... >>> EAP-TNC is designed to operate as an inner EAP [10] method over an >>> EAP tunnel method that meets the Requirements for a Tunnel Based >> EAP >>> Method [17]. PT-EAP therefore can operate over a number of >> existing >>> access protocols that support EAP for authentication. Some >> examples >>> of such access protocols include 802.1X [7] for wired and wireless >>> networks and IKEv2 [15] for establishing VPNs over IP networks. >> >> Does that mean that the data gathered at an endpoint via some NEA >> client >> would be available to party that controls the 802.1x or IKEv2 exchange? >> >> Would that data only be available after a successful 802.1x auth or >> tunnel >> negotiation? >> >> On 6/9/11 3:00 PM, "nea-request@ietf.org" wrote: >> >>> Message: 1 >>> Date: Thu, 9 Jun 2011 13:03:52 -0400 >>> From: Stephen Hanna >>> To: "nea@ietf.org" >>> Subject: [Nea] Pros and cons of EAP and TLVs for L2 PT >>> Message-ID: >>> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> As I mentioned in my recent email to the NEA list, the >>> PT draft editors have been working (as requested at the >>> last NEA WG meeting) on a list of pros and cons for >>> different approaches to the L2 PT protocol. This group >>> has now agreed on a set of pros and cons: >>> >>> EAP for PT >>> Pro: Can export keys (but no clear value at this time) >>> Pro: Multiple Interoperable Independent Implementations >>> Con: More likely to accidentally be used outside EAP tunnel >>> >>> TLVs for PT >>> Pro: Can run in parallel with authentication >>> >>> Of course, these are just bullet points. They're quite >>> short and don't capture all the nuances of the issues. >>> Let's start up an email discussion on the NEA list where >>> we can elaborate on these points and discuss them. In the >>> end, I hope that we can reach rough consensus on what is >>> the best approach. >>> >>> So let the discussion begin! >>> >>> Thanks, >>> >>> Steve >>> ====================================================================== Andreas Steffen andreas.steffen@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== From jsalowey@cisco.com Sun Jun 12 21:24:12 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0500121F84FD for ; Sun, 12 Jun 2011 21:24:12 -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=[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 M2thIx8njnTs for ; Sun, 12 Jun 2011 21:24:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 591CD21F84AE for ; Sun, 12 Jun 2011 21:24:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=2460; q=dns/txt; s=iport; t=1307939051; x=1309148651; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=iTDyQFP0hUtWk/IYhxPl81vD3suOB7vy4gg31R8hAMk=; b=kHUE34VG/OCAeXlWbgOnySErr1c0N3EyZU6/wRXTiz06DTD/erbQKYOI 9qJDBus700Ncw30ndq+pVVF9DGlogPze1O3l5BnWD29DGO1qTRF9PfiOE k52su9bgiqxD1MMy+/rzrdr70+TksngiL6cALIFLuDvIwRO24hQkrelV3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMqP9U2rRDoH/2dsb2JhbABSpk53iHKgcp0ShiQEhw2KJ4RPiy4 X-IronPort-AV: E=Sophos;i="4.65,356,1304294400"; d="scan'208";a="712302370" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 13 Jun 2011 04:24:09 +0000 Received: from [10.33.249.205] ([10.33.249.205]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5D4O8f2024820; Mon, 13 Jun 2011 04:24:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Sun, 12 Jun 2011 21:24:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Hanna X-Mailer: Apple Mail (2.1084) Cc: "nea@ietf.org" Subject: Re: [Nea] Pros and cons of EAP and TLVs for L2 PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 04:24:12 -0000 I have some concerns over using an EAP method to carry posture. EAP was = designed for peer and server authentication. Implementations and = deployments expect EAP methods to authenticate a peer and server name = which are often used for access control and/or accounting purposes. = Posture assessment does not necessary perform any authentication, so a = stand-alone posture based EAP may not be usable in many environments. = If posture assessment is tightly coupled with some authentication method = then it limits the capability to plug in different EAP authentication = methods in a deployment. Because of this disconnect between posture = assessment and authentication, assessment should not be a stand alone = EAP method, but rather a set of TLVs defined to be carried within an EAP = tunnel method. In addition, I am also concerned about the issues raised in the Prague = meeting over running posture unauthenticated outside a protect tunnel. = This is not a generally safe practice. There is a risk that a stand = alone posture assessment EAP method will run unprotected across some = portions of the network as is common practice today. Using TLVs within = a tunnel method would prevent the exposure of the posture assessment = through the normal operation of EAP. =20 Cheers, Joe On Jun 9, 2011, at 10:03 AM, Stephen Hanna wrote: > As I mentioned in my recent email to the NEA list, the > PT draft editors have been working (as requested at the > last NEA WG meeting) on a list of pros and cons for > different approaches to the L2 PT protocol. This group > has now agreed on a set of pros and cons: >=20 > EAP for PT > Pro: Can export keys (but no clear value at this time) > Pro: Multiple Interoperable Independent Implementations > Con: More likely to accidentally be used outside EAP tunnel >=20 > TLVs for PT > Pro: Can run in parallel with authentication >=20 > Of course, these are just bullet points. They're quite > short and don't capture all the nuances of the issues. > Let's start up an email discussion on the NEA list where > we can elaborate on these points and discuss them. In the > end, I hope that we can reach rough consensus on what is > the best approach. >=20 > So let the discussion begin! >=20 > Thanks, >=20 > Steve >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From internet-drafts@ietf.org Mon Jun 13 09:45:16 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D08011E80BE; Mon, 13 Jun 2011 09:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 1kY0DsM1wUSd; Mon, 13 Jun 2011 09:45:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA75B11E8144; Mon, 13 Jun 2011 09:45:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110613164506.9772.93161.idtracker@ietfa.amsl.com> Date: Mon, 13 Jun 2011 09:45:06 -0700 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-tls-00.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 16:45:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Endpoint Assessment Working G= roup of the IETF. Title : PT-TLS: A Posture Transport (PT) Protocol Based on Trans= port Layer Security (TLS) Author(s) : Paul Sangster Nancy Cam-Winget Joseph Salowey Filename : draft-ietf-nea-pt-tls-00.txt Pages : 49 Date : 2011-06-13 This document specifies PT-TLS, a Posture Transport (PT) protocol that carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-00.txt From shanna@juniper.net Fri Jun 24 13:32:23 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E036911E80BA for ; Fri, 24 Jun 2011 13:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIVKckD8njlN for ; Fri, 24 Jun 2011 13:32:23 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8F411E807A for ; Fri, 24 Jun 2011 13:32:22 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTgT0Ve0hm4q3PYbBwp266r65/qLrOLhI@postini.com; Fri, 24 Jun 2011 13:32:22 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 24 Jun 2011 13:26:55 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 24 Jun 2011 16:24:59 -0400 From: Stephen Hanna To: Joe Salowey Date: Fri, 24 Jun 2011 16:24:57 -0400 Thread-Topic: [Nea] Pros and cons of EAP and TLVs for L2 PT Thread-Index: Acwpgb/UrkcVdiiHQJu7oqCS4UVpBQAID+oQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nea@ietf.org" Subject: Re: [Nea] Pros and cons of EAP and TLVs for L2 PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 20:32:24 -0000 Certainly, it's not safe to run PT-EAP (or any of the other PTs proposed so far) outside an EAP tunnel method. Nesting in an EAP tunnel method is clearly required in all the PT proposals. I expect that the final L2 PT RFC will clearly state that it MUST only be run inside an EAP tunnel method. One could create an L2 PT that would be safe to run outside an EAP tunnel method by adding authentication but there's no point in doing so since we already have EAP tunnel methods and usually it's desirable to combine user or endpoint authentication with posture assessment. So I think we have established that the requirement to run the L2 PT in an EAP tunnel method does not differ from one proposed L2 PT approach to another. Your contention that implementing L2 PT as an EAP method will cause difficulties for EAP implementations and deployments is not supported by the evidence. As documented in the slides for the NEA WG meeting at IETF 80, there are at least nine separate implementations of PT-EAP in use today. I have spoken to almost all of the implementers and several deployers, asking for feedback on the PT-EAP specification. I have not heard any complaints that the use of an EAP method as a posture transport caused any difficulties. In fact, I have been told that it made the implementation easier since they didn't have to modify their user interfaces. They already have a way for administrators and users to select which inner EAP methods should be used in an EAP tunnel method. This same technique was used to enable PT-EAP. In order to further this discussion, I'm going to write a separate email to elaborate on the pros and cons listed in the original email on this thread. Thanks, Steve > -----Original Message----- > From: Joe Salowey [mailto:jsalowey@cisco.com] > Sent: Monday, June 13, 2011 12:25 AM > To: Stephen Hanna > Cc: nea@ietf.org > Subject: Re: [Nea] Pros and cons of EAP and TLVs for L2 PT >=20 > I have some concerns over using an EAP method to carry posture. EAP > was designed for peer and server authentication. Implementations and > deployments expect EAP methods to authenticate a peer and server name > which are often used for access control and/or accounting purposes. > Posture assessment does not necessary perform any authentication, so a > stand-alone posture based EAP may not be usable in many environments. > If posture assessment is tightly coupled with some authentication > method then it limits the capability to plug in different EAP > authentication methods in a deployment. Because of this disconnect > between posture assessment and authentication, assessment should not be > a stand alone EAP method, but rather a set of TLVs defined to be > carried within an EAP tunnel method. >=20 > In addition, I am also concerned about the issues raised in the Prague > meeting over running posture unauthenticated outside a protect tunnel. > This is not a generally safe practice. There is a risk that a stand > alone posture assessment EAP method will run unprotected across some > portions of the network as is common practice today. Using TLVs within > a tunnel method would prevent the exposure of the posture assessment > through the normal operation of EAP. >=20 > Cheers, >=20 > Joe > On Jun 9, 2011, at 10:03 AM, Stephen Hanna wrote: >=20 > > As I mentioned in my recent email to the NEA list, the > > PT draft editors have been working (as requested at the > > last NEA WG meeting) on a list of pros and cons for > > different approaches to the L2 PT protocol. This group > > has now agreed on a set of pros and cons: > > > > EAP for PT > > Pro: Can export keys (but no clear value at this time) > > Pro: Multiple Interoperable Independent Implementations > > Con: More likely to accidentally be used outside EAP tunnel > > > > TLVs for PT > > Pro: Can run in parallel with authentication > > > > Of course, these are just bullet points. They're quite > > short and don't capture all the nuances of the issues. > > Let's start up an email discussion on the NEA list where > > we can elaborate on these points and discuss them. In the > > end, I hope that we can reach rough consensus on what is > > the best approach. > > > > So let the discussion begin! > > > > Thanks, > > > > Steve > > > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www.ietf.org/mailman/listinfo/nea From shanna@juniper.net Fri Jun 24 14:49:19 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 0832E21F84D9 for ; Fri, 24 Jun 2011 14:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRetrkSZfNnf for ; Fri, 24 Jun 2011 14:49:18 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id E9F7021F84D8 for ; Fri, 24 Jun 2011 14:49:17 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTgUGXd14KISy/yRZM34beBmIXwP5ZoDB@postini.com; Fri, 24 Jun 2011 14:49:17 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 24 Jun 2011 14:46:43 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 24 Jun 2011 17:46:42 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Fri, 24 Jun 2011 17:46:41 -0400 Thread-Topic: Pros and cons of EAP and TLVs for L2 PT Thread-Index: AcwmxzWngKxgsxSdQCmkmLD+c6DQ5gL5kkVg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Nea] Pros and cons of EAP and TLVs for L2 PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2011 21:49:19 -0000 In this message, I'm going to expand on the pros and cons that were originally listed for the EAP and TLV approaches. These are my personal views, of course. Chair hat off! > EAP for PT > Pro: Can export keys (but no clear value at this time) As described in RFC 5247, many EAP methods export keys (MSK, EMSK, IV) for use by lower-layer protocols such as IEEE 802.11 and IKEv2. These keys can also be used to bind inner EAP methods to outer EAP tunnel methods, preventing an Asokan attack. Since L2 PT protocols are not supposed to be used outside a tunnel method and another technique for addressing Asokan attacks is already in all L2 PT protocols (TLS-Unique), there is no clear value to exporting keys from an L2 PT. Still, it makes me nervous to give up the ability to use this feature in the future if a new attack is discovered that can be addressed in this manner. > Pro: Multiple Interoperable Independent Implementations Do we still believe in running code? Certainly, this should not be the sole determining factor in deciding which approach to take but it seems that it should be a factor. PT-EAP has 9 implementations. EAP-TLV has 1. I would like to mention that one of the reasons why there are so many implementations of PT-EAP is that PT-EAP is a TCG standard: IF-T Protocol Bindings for Tunneled EAP Methods (also known as EAP-TNC). RFC 5209 (our requirements document) includes this requirement: C-5 The selection process for NEA protocols MUST evaluate and prefer the reuse of existing open standards that meet the requirements before defining new ones. The goal of NEA is not to create additional alternative protocols where acceptable solutions already exist. The proponents of EAP-TLV have argued that TCG standards are not really open standards. Of course, there is no one definition of the phrase "open standards" but TCG standards fall into a similar category as SAML and XACML: developed by an industry consortium and made available to all for free. Another benefit of choosing a TNC standard is that they have received security reviews from several organizations. One of these reviews turned up the Asokan attack on posture checking, which was immediately addressed (as were other secure issues raised). > Con: More likely to accidentally be used outside EAP tunnel While this is true in theory, I think we can avoid the problem by stating in the specification that implementers MUST NOT permit this method to be sent outside a tunnel EAP method. It's possible that implementers will ignore our requirement but I expect that TCG will offer certification for products that implement the L2 PT (as it has done for other TNC standards) so any violation of such a requirement would be caught during the certification process and flagged as a violation. > TLVs for PT > Pro: Can run in parallel with authentication This is definitely a valid point in favor of the TLV approach. Running posture checking in parallel with authentication could reduce the number of round trips needed for EAP. On the other hand, running posture checking and authentication in parallel could increase the complexity of implementation. And it would be REALLY complex to make support for parallel posture checking optional so I think we'll need to either require NEA clients to support parallel posture checking or prohibit this feature. One thing to note is that parallel posture checking is sometimes not desired. The set of posture checks needed may depend on the user's identity or role. In that case, you would want to run the authentication before the posture check. And some organizations avoid prompting the user for authentication credentials until after the endpoint has passed a posture check. In that case, you want to run the posture check before the authentication. So I don't see this as being much of a Pro. **Summary** In summary, I think that we could go either way: TLV or EAP method. There are Pros and Cons on both sides but none of them are really substantial. Therefore, I think we should favor the proposal that is based on open standards, as required by our requirements document: PT-EAP. This protocol has been implemented widely and has received many security reviews. In contrast, the EAP-TLV proposal (as pointed out in my slides for IETF 80) is clearly not even a complete proposal. It's missing key features like versioning and support for PB messages other than PB-PA and has race conditions. It's just a sketch, not ready for prime time. Well, that's my view, anyway. Thanks, Steve From shanna@juniper.net Fri Jun 24 17:09:48 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 D84279E8018 for ; Fri, 24 Jun 2011 17:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPA7-tN3IoRI for ; Fri, 24 Jun 2011 17:09:46 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1734A9E8004 for ; Fri, 24 Jun 2011 17:09:43 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTgUnR/uqOjBtMgCEQnvUPlrRn438lS7q@postini.com; Fri, 24 Jun 2011 17:09:44 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 24 Jun 2011 17:06:20 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 24 Jun 2011 20:04:18 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Fri, 24 Jun 2011 20:04:17 -0400 Thread-Topic: Nomcom 2011-2012: Second Call for Volunteers Thread-Index: AcwymtwU8WlB/M4KTa6GSr8B3aR/LwAFwABA Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Nea] FW: Nomcom 2011-2012: Second Call for Volunteers X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 00:09:48 -0000 NEA WG Participants, Please volunteer for the IETF NomCom if you're eligible. This is an important part of being an IETF participant. BTW, I have served on the NomCom twice. I learned a lot. The benefits of service definitely exceeded the costs. Thanks, Steve -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org= ] On Behalf Of NomCom Chair Sent: Friday, June 24, 2011 2:14 PM To: IETF Announcement list Subject: Nomcom 2011-2012: Second Call for Volunteers=20 This is the Second call for Volunteers for the 2011-12 Nomcom. We are just about halfway through the volunteer period so if you are considering volunteering, please do so very soon.=20 We have had a very good response to the initial call for volunteers and I am pleased to report that we have 50 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. =20 However, we would like to have many more volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross=20 section of the IETF population. You have until 11:59 pm EDT July 10, 2011=20 to volunteer for Nomcom but it would be much better if you can volunteer=20 as early as possible.=20 If you volunteered before 21:00 EDT on June 21 to serve as a voting member and have not received a confirmation email from me, please re-submit and=20 bring to my attention right away! =20 Details about the process for volunteering for the Nomcom and the list=20 of open positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2938/ The 50 volunteers who have thus far been qualified by the secretariat are:=20 Alia Atlas , Juniper Networks Lixia Zhang , UCLA Wassim Haddad , Ericsson Glen Zorn , Network Zen Richard Barnes , BBN Technologies Stephen Kent , BBN Technologies Scott Mansfield , Ericsson Tina TSOU , FutureWei Technologies Fernando Gont , UTN/FRH Karen Seo , BBN Technologies Jie Dong , Huawei Technologies Mach Chen , Huawei Technologies Co. Sheng Jiang , Huawei Technologies Co. Ltd. Dimitri Papadimitriou , Alcatel-Lucent Thomas D. Nadeau , CA Technologies David Meyer , Cisco Systems/University of Oregon Wesley George , Time Warner Cable Cullen Jennings , Cisco Stephen Hanna , Juniper Networks Stephan Wenger , Bidyo Keyur Patel , Cisco Systems Michael Hamilton , BreakingPoint Systems Behcet Sarikaya , Huawei USA Mark Townsley , Cisco Systems Fred Baker , Cisco Systems Brian Trammell , ETH Zurich Sam Hartman , Painless Security Chris Griffiths , Comcast George Michaelson , APNIC Jiankang Yao , CNNIC Sohel Khan , Comcast Dacheng Zhang , Huawei Lianshu Zheng , Huawei Technologies Hui Deng , China Mobile Gang Chen , China Mobile Mirja Kuhlewind , University of Stuttgart John E Drake , Juniper Networks Matt Lepinski , BBN Technologies Subir Das , Telcordia Technologies Inc Yi Zhao , Huawei John Scudder , Juniper Networks Christer Holmberg , LM Ericsson Teemu Savolainen , Nokia Samita Chakrabarti , Ericsson Jaap Akkerhuis , NLnet labs Jason Weil , Time Warner Cable Randy Bush , Internet Initiative Japan Christian Schmidt , Nokia Siemens Networks Sean Shen , CNNIC Lou Berger , LabN Consulting The primary activity for this nomcom will begin during IETF-81 in Quebec City and should be completed by January 2012. The nomcom will be collecting requirements from the community, as well as talking to candidates and to community members about candidates. There will be regularly scheduled conference calls to ensure progress. Thus, being a nomcom member does require some time commitment. =20 Please volunteer by sending an email to me before=20 11:59 pm EDT July 10, 2011 as follows: To: suresh.krishnan@ericsson.com Subject: Nomcom 2011-12 Volunteer Please include the following information in the body of the mail: Full Name: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name Current Primary Affiliation: // typically what goes in the Company=20 // field in the IETF Registration Form Email Address(es): // all email addresses used to Register for the=20 // past 5 IETF meetings // Please designate a Preferred email address for // contact if there is more than one email address Telephone number: // With country code (for confirmation if selected) Please expect an email response from me within 3 business days stating whether or not you are qualified. If you do not receive a response in this timeframe, please re-send your email with the tag "RESEND:" added to the subject line. If you are not yet sure you would like to volunteer, please consider that Nomcom members play a very important role in shaping the leadership of the IETF. Ensuring the leadership of the IETF is fair and balanced and comprised of those who can lead the IETF in the right direction is an important responsibility that rests on the IETF participants at large. Volunteering for the Nomcom is a good way of contributing in that direction. I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process within the next few days. Thank you in advance for your participation. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From latze@angry-red-pla.net Sat Jun 25 12:24:51 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 E648A11E80EE for ; Sat, 25 Jun 2011 12:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 CsBqNS9mL-1B for ; Sat, 25 Jun 2011 12:24:50 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5D411E80CB for ; Sat, 25 Jun 2011 12:24:49 -0700 (PDT) Received: from [192.168.1.97] (228-47.104-92.cust.bluewin.ch [92.104.47.228]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0Mb5Ch-1Qu9gx1IbL-00Kg68; Sat, 25 Jun 2011 21:24:48 +0200 Message-ID: <4E0635FF.3090406@angry-red-pla.net> Date: Sat, 25 Jun 2011 21:24:47 +0200 From: Carolin Latze User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: nea@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:RV/DgqsI9V40IhUoFVVJruBVdG7fqmLH6vKofxcUhAV 3hkAZjI8CizMOmXla5Y7yD/E10YkgrudW6kiDHyfdPver9syt1 qYchgPf5fwNaKda1+LwCAnyrRJ5FgKwjldFeejbrIHrKl0EHLi VaPSMeelq5HOEgElnachfy5bExT5B8CF8i0ZVKd1ePe1F8LKDf qBy8NmbGu5Kehd5wRo01xWsIqke23YtQETkT0mcKBE= Subject: Re: [Nea] Pros and cons of EAP and TLVs for L2 PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jun 2011 19:24:51 -0000 In general I think it is a good idea to take the proposal that has already implementations (will be easier deployed on a large scale). Furthermore I don't think it is really a problem that PT-EAP should never run outside a tunnel. There are more EAP methods available that could run outside a tunnel but shouldn't (such as EAP-MD5, ...). However I see the point that PT-EAP is no authentication method. But as PT-EAP has some implementations and might become a de-facto standard anyways, it might still make sense to go for PT-EAP. Regards Carolin From jsalowey@cisco.com Tue Jun 28 09:55:12 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060CB11E80E6 for ; Tue, 28 Jun 2011 09:55:12 -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=[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 FwQ6HBcGE48I for ; Tue, 28 Jun 2011 09:55:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA6A11E80E4 for ; Tue, 28 Jun 2011 09:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=5440; q=dns/txt; s=iport; t=1309280111; x=1310489711; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fpLR70CxR4XNxPNIkXwFq7ZfAUUbYyc+MBHZOBLPXE8=; b=etPINGPwUy6FcoBngBDpMb8elnE4AJjDmnzw4ixT3xn3E9y17LFLnM1G URnBOTkpuuO7DlVYj0LnfoWoJ+iXHZ4LKh/dC5v51nBdFqthI7L0Ui144 VhmAtKdGF5baVbQ0/15L3KyAZ+ylTCgWbuEskQXCoRUUHk+aIAA/FSMNi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoAAK4GCk6rRDoH/2dsb2JhbABSmAyPNHeId6IzniiGMASHNIpchG6LUw X-IronPort-AV: E=Sophos;i="4.65,437,1304294400"; d="scan'208";a="723535102" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 28 Jun 2011 16:55:09 +0000 Received: from [10.33.248.247] ([10.33.248.247]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5SGt9Nh011175; Tue, 28 Jun 2011 16:55:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Tue, 28 Jun 2011 09:55:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Hanna X-Mailer: Apple Mail (2.1084) Cc: "nea@ietf.org" Subject: Re: [Nea] Pros and cons of EAP and TLVs for L2 PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 16:55:12 -0000 On Jun 24, 2011, at 1:24 PM, Stephen Hanna wrote: > Certainly, it's not safe to run PT-EAP (or any of the other PTs > proposed so far) outside an EAP tunnel method. Nesting in an > EAP tunnel method is clearly required in all the PT proposals. > I expect that the final L2 PT RFC will clearly state that it > MUST only be run inside an EAP tunnel method. One could create > an L2 PT that would be safe to run outside an EAP tunnel method > by adding authentication but there's no point in doing so since > we already have EAP tunnel methods and usually it's desirable > to combine user or endpoint authentication with posture assessment. >=20 > So I think we have established that the requirement to run the > L2 PT in an EAP tunnel method does not differ from one proposed > L2 PT approach to another. >=20 [Joe] My biggest concern is the execution of PT-EAP outside the = protected tunnel. If the method is "hidden" inside a tunnel method then = the impact to the external system can be mitigated. I still have = concern that using EAP framing for posture is not appropriate and will = lead to special case code inside the tunnel method specifically to = handle the method. =20 > Your contention that implementing L2 PT as an EAP method will > cause difficulties for EAP implementations and deployments is > not supported by the evidence. As documented in the slides for > the NEA WG meeting at IETF 80, there are at least nine separate > implementations of PT-EAP in use today. I have spoken to almost > all of the implementers and several deployers, asking for > feedback on the PT-EAP specification. I have not heard any > complaints that the use of an EAP method as a posture transport > caused any difficulties. In fact, I have been told that it made > the implementation easier since they didn't have to modify their > user interfaces. They already have a way for administrators and > users to select which inner EAP methods should be used in an > EAP tunnel method. This same technique was used to enable PT-EAP. >=20 [Joe] This worries me a bit and illustrates my concern. Most of the = user interfaces I have seen only allow the selection of a single inner = method. If only a single inner method is selected you are either not = performing authentication or you are performing an authentication that = is specific to your PT-EAP implementation. =20 > In order to further this discussion, I'm going to write a > separate email to elaborate on the pros and cons listed in > the original email on this thread. >=20 > Thanks, >=20 > Steve >=20 >> -----Original Message----- >> From: Joe Salowey [mailto:jsalowey@cisco.com] >> Sent: Monday, June 13, 2011 12:25 AM >> To: Stephen Hanna >> Cc: nea@ietf.org >> Subject: Re: [Nea] Pros and cons of EAP and TLVs for L2 PT >>=20 >> I have some concerns over using an EAP method to carry posture. EAP >> was designed for peer and server authentication. Implementations = and >> deployments expect EAP methods to authenticate a peer and server name >> which are often used for access control and/or accounting purposes. >> Posture assessment does not necessary perform any authentication, so = a >> stand-alone posture based EAP may not be usable in many environments. >> If posture assessment is tightly coupled with some authentication >> method then it limits the capability to plug in different EAP >> authentication methods in a deployment. Because of this disconnect >> between posture assessment and authentication, assessment should not = be >> a stand alone EAP method, but rather a set of TLVs defined to be >> carried within an EAP tunnel method. >>=20 >> In addition, I am also concerned about the issues raised in the = Prague >> meeting over running posture unauthenticated outside a protect = tunnel. >> This is not a generally safe practice. There is a risk that a stand >> alone posture assessment EAP method will run unprotected across some >> portions of the network as is common practice today. Using TLVs = within >> a tunnel method would prevent the exposure of the posture assessment >> through the normal operation of EAP. >>=20 >> Cheers, >>=20 >> Joe >> On Jun 9, 2011, at 10:03 AM, Stephen Hanna wrote: >>=20 >>> As I mentioned in my recent email to the NEA list, the >>> PT draft editors have been working (as requested at the >>> last NEA WG meeting) on a list of pros and cons for >>> different approaches to the L2 PT protocol. This group >>> has now agreed on a set of pros and cons: >>>=20 >>> EAP for PT >>> Pro: Can export keys (but no clear value at this time) >>> Pro: Multiple Interoperable Independent Implementations >>> Con: More likely to accidentally be used outside EAP tunnel >>>=20 >>> TLVs for PT >>> Pro: Can run in parallel with authentication >>>=20 >>> Of course, these are just bullet points. They're quite >>> short and don't capture all the nuances of the issues. >>> Let's start up an email discussion on the NEA list where >>> we can elaborate on these points and discuss them. In the >>> end, I hope that we can reach rough consensus on what is >>> the best approach. >>>=20 >>> So let the discussion begin! >>>=20 >>> Thanks, >>>=20 >>> Steve >>>=20 >>> _______________________________________________ >>> Nea mailing list >>> Nea@ietf.org >>> https://www.ietf.org/mailman/listinfo/nea >=20 From jsalowey@cisco.com Tue Jun 28 10:18:10 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 EFCF8228006 for ; Tue, 28 Jun 2011 10:18:10 -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=[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 ueMrjPDoqyXA for ; Tue, 28 Jun 2011 10:18:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 3A91921F85B0 for ; Tue, 28 Jun 2011 10:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=6687; q=dns/txt; s=iport; t=1309281490; x=1310491090; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=izaTl8ztBDUGSQgl3L5/M9iHL8elGqDLUGOemcEBznc=; b=RYNuUj47AItzKp1WTP87atyu5+fWOuIpvT+gQfYWmTPEw06hKqdkaYFx 3sIgtfC0+poHJVA2d6tyToApjlYGXl53qazQCG7f4t0CQSWzLaq4/9jUS IDZf1IDCUMbb39WvQqnaQPKynohojLx54v8RrPGCbZls6dYCY9WHBeZuK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADIMCk6rRDoH/2dsb2JhbABFDadAd4h3oi6eKYMggxAEhzSKXIRui1M X-IronPort-AV: E=Sophos;i="4.65,437,1304294400"; d="scan'208";a="723552447" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-6.cisco.com with ESMTP; 28 Jun 2011 17:18:09 +0000 Received: from [10.33.248.247] ([10.33.248.247]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5SHI9Kx004178; Tue, 28 Jun 2011 17:18:09 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Tue, 28 Jun 2011 10:18:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <548CC78B-2E37-4CE9-A9B5-553B0379E6B0@cisco.com> References: To: Stephen Hanna X-Mailer: Apple Mail (2.1084) Cc: "nea@ietf.org" Subject: Re: [Nea] Pros and cons of EAP and TLVs for L2 PT X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2011 17:18:11 -0000 On Jun 24, 2011, at 2:46 PM, Stephen Hanna wrote: > In this message, I'm going to expand on the pros and cons > that were originally listed for the EAP and TLV approaches. > These are my personal views, of course. Chair hat off! >=20 >> EAP for PT >> Pro: Can export keys (but no clear value at this time) >=20 > As described in RFC 5247, many EAP methods export keys > (MSK, EMSK, IV) for use by lower-layer protocols such as > IEEE 802.11 and IKEv2. These keys can also be used to > bind inner EAP methods to outer EAP tunnel methods, > preventing an Asokan attack. Since L2 PT protocols are > not supposed to be used outside a tunnel method and > another technique for addressing Asokan attacks is > already in all L2 PT protocols (TLS-Unique), there > is no clear value to exporting keys from an L2 PT. > Still, it makes me nervous to give up the ability > to use this feature in the future if a new attack > is discovered that can be addressed in this manner. >=20 [Joe] At this point, as you state, I don't see significant value in = exporting keys. If the posture process does generate key material then = this can be used in whatever way is appropriate. Its not clear to me at = this point if you would want to use these keys in the exact same way you = would use keys exported from a mutual authentication. =20 >> Pro: Multiple Interoperable Independent Implementations >=20 > Do we still believe in running code? Certainly, this > should not be the sole determining factor in deciding > which approach to take but it seems that it should be > a factor. PT-EAP has 9 implementations. EAP-TLV has 1. >=20 > I would like to mention that one of the reasons why there > are so many implementations of PT-EAP is that PT-EAP is > a TCG standard: IF-T Protocol Bindings for Tunneled EAP > Methods (also known as EAP-TNC). RFC 5209 (our requirements > document) includes this requirement: >=20 > C-5 The selection process for NEA protocols MUST evaluate and = prefer > the reuse of existing open standards that meet the requirements > before defining new ones. The goal of NEA is not to create > additional alternative protocols where acceptable solutions > already exist. >=20 > The proponents of EAP-TLV have argued that TCG standards > are not really open standards. Of course, there is no one > definition of the phrase "open standards" but TCG standards > fall into a similar category as SAML and XACML: developed by > an industry consortium and made available to all for free. >=20 > Another benefit of choosing a TNC standard is that they > have received security reviews from several organizations. > One of these reviews turned up the Asokan attack on posture > checking, which was immediately addressed (as were other > secure issues raised). >=20 [Joe] My concern is the existing implementations are special casing the = inner PT-EAP method. Since the work is already done it may not be a = huge issue, however I don't think moving to a TLV framing would be a = huge burden and I think in the long term it will be a more flexible = approach. =20 >> Con: More likely to accidentally be used outside EAP tunnel >=20 > While this is true in theory, I think we can avoid the problem > by stating in the specification that implementers MUST NOT > permit this method to be sent outside a tunnel EAP method. > It's possible that implementers will ignore our requirement > but I expect that TCG will offer certification for products > that implement the L2 PT (as it has done for other TNC standards) > so any violation of such a requirement would be caught during > the certification process and flagged as a violation. >=20 [Joe] If we go down the EAP route then I think this requirement and = testing would be good as it brings the two proposals closer in terms of = security. =20 >> TLVs for PT >> Pro: Can run in parallel with authentication >=20 > This is definitely a valid point in favor of the TLV approach. > Running posture checking in parallel with authentication could > reduce the number of round trips needed for EAP. On the other > hand, running posture checking and authentication in parallel > could increase the complexity of implementation. And it would > be REALLY complex to make support for parallel posture checking > optional so I think we'll need to either require NEA clients to > support parallel posture checking or prohibit this feature. >=20 > One thing to note is that parallel posture checking is sometimes > not desired. The set of posture checks needed may depend on the > user's identity or role. In that case, you would want to run the > authentication before the posture check. And some organizations > avoid prompting the user for authentication credentials until > after the endpoint has passed a posture check. In that case, > you want to run the posture check before the authentication. >=20 > So I don't see this as being much of a Pro. >=20 [Joe] I agree that this is not useful in all cases, but in cases where = posture and authentication do not depend upon one another I do not see = that there is much complexity here and it can reduce the number of round = trips. I guess I don't see having it be optional as a huge complexity = as an endpoint could signal whether it allows posture at a particular = point in the process or not. =20 > **Summary** >=20 > In summary, I think that we could go either way: TLV or EAP > method. There are Pros and Cons on both sides but none of > them are really substantial. >=20 > Therefore, I think we should favor the proposal that is > based on open standards, as required by our requirements > document: PT-EAP. This protocol has been implemented widely > and has received many security reviews. In contrast, the > EAP-TLV proposal (as pointed out in my slides for IETF 80) > is clearly not even a complete proposal. It's missing key > features like versioning and support for PB messages other > than PB-PA and has race conditions. It's just a sketch, > not ready for prime time. Well, that's my view, anyway. >=20 [Joe] I don't think the delta is that great either and moving to a = different framing would not be too burdensome. While there may be some = gaps in the current TLV definition these can be improved if the group = feels that decoupling posture and authentication provides more = flexibility, efficiency and security.=20 > Thanks, >=20 > Steve >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From wwwrun@rfc-editor.org Tue Jun 28 11:43:12 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5A111E8169 for ; Tue, 28 Jun 2011 11:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 nDXG4cfq8gFc for ; Tue, 28 Jun 2011 11:43:11 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by ietfa.amsl.com (Postfix) with ESMTP id D293811E8167 for ; Tue, 28 Jun 2011 11:43:11 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BB71598C4F4; Tue, 28 Jun 2011 11:43:11 -0700 (PDT) To: Ravi.Sahita@intel.com, shanna@juniper.net, Ryan.Hurst@microsoft.com, kaushik@cisco.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, sethomso@cisco.com, shanna@juniper.net From: RFC Errata System Message-Id: <20110628184311.BB71598C4F4@rfc-editor.org> Date: Tue, 28 Jun 2011 11:43:11 -0700 (PDT) X-Mailman-Approved-At: Tue, 28 Jun 2011 11:44:57 -0700 Cc: rfc-editor@rfc-editor.org, nea@ietf.org, andreas.steffen@hsr.ch Subject: [Nea] [Technical Errata Reported] RFC5793 (2848) 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, 28 Jun 2011 18:43:12 -0000 The following errata report has been submitted for RFC5793, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5793&eid=2848 -------------------------------------- Type: Technical Reported by: Andreas Steffen Section: 4.8.1 Original Text ------------- Remediation String (variable length) The Remediation String field MUST contain a UTF-8 [6] encoded string. This string contains human-readable instructions for remediation that MAY be displayed to the user by the Posture Broker Client. NUL termination MUST NOT be included. If a Posture Broker Client receives a Reason String that does contain a NUL termination, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. Corrected Text -------------- Remediation String (variable length) The Remediation String field MUST contain a UTF-8 [6] encoded string. This string contains human-readable instructions for remediation that MAY be displayed to the user by the Posture Broker Client. NUL termination MUST NOT be included. If a Posture Broker Client receives a Remediation String that does contain a NUL termination, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. Notes ----- Copy-and-paste error: Reason String must be changed to Remediation String. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5793 (draft-ietf-nea-pb-tnc-06) -------------------------------------- Title : PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) Publication Date : March 2010 Author(s) : R. Sahita, S. Hanna, R. Hurst, K. Narayan Category : PROPOSED STANDARD Source : Network Endpoint Assessment Area : Security Stream : IETF Verifying Party : IESG From shanna@juniper.net Thu Jun 30 07:52:46 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 0D97111E8100 for ; Thu, 30 Jun 2011 07:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9GDNLpgHlxh for ; Thu, 30 Jun 2011 07:52:45 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 45A6411E8092 for ; Thu, 30 Jun 2011 07:52:41 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTgyNq+uCcjz+slreeB7i55piKHRXn4lU@postini.com; Thu, 30 Jun 2011 07:52:45 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 30 Jun 2011 07:49:12 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 30 Jun 2011 10:49:12 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Thu, 30 Jun 2011 10:49:11 -0400 Thread-Topic: Seeking Consensus on Errata 2848 Against RFC 5793 Thread-Index: Acw1wz3kfWSnByd6SqimotbIl/Y2+gBTYrUQ Message-ID: References: <20110628184311.BB71598C4F4@rfc-editor.org> In-Reply-To: <20110628184311.BB71598C4F4@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Ryan.Hurst@microsoft.com" , "andreas.steffen@hsr.ch" , "turners@ieca.com" , "rfc-editor@rfc-editor.org" Subject: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793 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, 30 Jun 2011 14:52:46 -0000 I talked with our ADs about how to handle the errata described below. We agree that the best thing is to have the NEA WG discuss it and come to a consensus recommendation on the proper resolution. If the ADs agree, they'll go ahead and implement our recommendation. As one of the editors of RFC 5793, I'd say this errata is pretty obviously correct. The paragraph in question is talking about the Remediation String. The one occurrence of Reason String in the text must have been a copy-paste error in the development of the document. The other thing to consider is whether the errata should be Approved (and therefore published in the RFC Editor's errata database) or marked Hold For Document Update (in which case it's simply set aside for a future revision of this RFC). The criterion to be used here is whether the issue "could cause implementation or deployment problems or significant confusion". This is a tougher call but I'd say that it could cause implementation or deployment problems. If an implementer reads the erroneous text at face value, he/she would skip the mandatory NUL terminator check for Remediation String. That could result in interoperability problems since a NEA Server that sends a NUL terminator on the Remediation String would work fine with one NEA Client but not with another. So I think the errata should be Approved. Do you agree? Let's see some discussion or simply Agree/Disagree emails so that we can reach consensus. Susan and I plan to close this discussion in two weeks (end of July 14) so please respond by then. BTW, kudos to Andreas for finding and reporting this problem! Thanks, Steve > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Tuesday, June 28, 2011 2:43 PM > To: Ravi.Sahita@intel.com; Stephen Hanna; Ryan.Hurst@microsoft.com; > kaushik@cisco.com; stephen.farrell@cs.tcd.ie; turners@ieca.com; > sethomso@cisco.com; Stephen Hanna > Cc: andreas.steffen@hsr.ch; nea@ietf.org; rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC5793 (2848) >=20 >=20 > The following errata report has been submitted for RFC5793, > "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network > Connect (TNC)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D5793&eid=3D2848 >=20 > -------------------------------------- > Type: Technical > Reported by: Andreas Steffen >=20 > Section: 4.8.1 >=20 > Original Text > ------------- > Remediation String (variable length) >=20 >=20 >=20 > The Remediation String field MUST contain a UTF-8 [6] encoded >=20 > string. This string contains human-readable instructions for >=20 > remediation that MAY be displayed to the user by the Posture >=20 > Broker Client. NUL termination MUST NOT be included. If a >=20 > Posture Broker Client receives a Reason String that does contain > a >=20 > NUL termination, it MUST respond with a fatal Invalid Parameter >=20 > error in a CLOSE batch. >=20 >=20 >=20 > Corrected Text > -------------- > Remediation String (variable length) >=20 >=20 >=20 > The Remediation String field MUST contain a UTF-8 [6] encoded >=20 > string. This string contains human-readable instructions for >=20 > remediation that MAY be displayed to the user by the Posture >=20 > Broker Client. NUL termination MUST NOT be included. If a >=20 > Posture Broker Client receives a Remediation String that does > contain a >=20 > NUL termination, it MUST respond with a fatal Invalid Parameter >=20 > error in a CLOSE batch. >=20 > Notes > ----- > Copy-and-paste error: Reason String must be changed to Remediation > String. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC5793 (draft-ietf-nea-pb-tnc-06) > -------------------------------------- > Title : PB-TNC: A Posture Broker (PB) Protocol Compatible > with Trusted Network Connect (TNC) > Publication Date : March 2010 > Author(s) : R. Sahita, S. Hanna, R. Hurst, K. Narayan > Category : PROPOSED STANDARD > Source : Network Endpoint Assessment > Area : Security > Stream : IETF > Verifying Party : IESG From Kent_Landfield@mcafee.com Thu Jun 30 08:11:15 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 097AB11E8187 for ; Thu, 30 Jun 2011 08:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s73pcNh3FtLN for ; Thu, 30 Jun 2011 08:11:13 -0700 (PDT) Received: from dalsmrelay2.nai.com (dalsmrelay2.nai.com [205.227.136.216]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC7911E8182 for ; Thu, 30 Jun 2011 08:11:13 -0700 (PDT) Received: from (unknown [10.64.5.51]) by dalsmrelay2.nai.com with smtp id 7f5e_ac50_2f6fd88c_a32b_11e0_b359_00219b929abd; Thu, 30 Jun 2011 10:11:09 -0500 Received: from AMERDALEXMB1.corp.nai.org ([fe80::b534:4a0d:1289:2d2d]) by DALEXHT1.corp.nai.org ([::1]) with mapi; Thu, 30 Jun 2011 10:10:27 -0500 From: To: , Date: Thu, 30 Jun 2011 10:10:26 -0500 Thread-Topic: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793 Thread-Index: Acw3N9gC7qAmSfs+ROqo/EjzRo2YMg== 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.12.0.110505 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: turners@ieca.com, rfc-editor@rfc-editor.org, Ryan.Hurst@microsoft.com, andreas.steffen@hsr.ch Subject: Re: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:11:15 -0000 I agree this is a tougher call on the implementation / deployment issue but= this should be made obvious to developers so we remove the potential probl= em. I would like to see the errata approved. Kent Landfield Director Content Strategy, Architecture and Standards McAfee, Inc. 5000 Headquarters Dr. Plano, Texas 75024 Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com From: Stephen Hanna > Date: Thu, 30 Jun 2011 09:49:11 -0500 To: "nea@ietf.org" > Cc: "Ryan.Hurst@microsoft.com" >, "andreas.steffen@hsr.ch" >, "turners@ieca.com" >, "rfc-editor@rfc-editor.org" > Subject: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793 I talked with our ADs about how to handle the errata described below. We agree that the best thing is to have the NEA WG discuss it and come to a consensus recommendation on the proper resolution. If the ADs agree, they'll go ahead and implement our recommendation. As one of the editors of RFC 5793, I'd say this errata is pretty obviously correct. The paragraph in question is talking about the Remediation String. The one occurrence of Reason String in the text must have been a copy-paste error in the development of the document. The other thing to consider is whether the errata should be Approved (and therefore published in the RFC Editor's errata database) or marked Hold For Document Update (in which case it's simply set aside for a future revision of this RFC). The criterion to be used here is whether the issue "could cause implementation or deployment problems or significant confusion". This is a tougher call but I'd say that it could cause implementation or deployment problems. If an implementer reads the erroneous text at face value, he/she would skip the mandatory NUL terminator check for Remediation String. That could result in interoperability problems since a NEA Server that sends a NUL terminator on the Remediation String would work fine with one NEA Client but not with another. So I think the errata should be Approved. Do you agree? Let's see some discussion or simply Agree/Disagree emails so that we can reach consensus. Susan and I plan to close this discussion in two weeks (end of July 14) so please respond by then. BTW, kudos to Andreas for finding and reporting this problem! Thanks, Steve -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] Sent: Tuesday, June 28, 2011 2:43 PM To: Ravi.Sahita@intel.com; Stephen Hanna; Rya= n.Hurst@microsoft.com; kaushik@cisco.com; stephen.farrell@cs.tcd.ie; turners@ieca.com; sethomso@cisco.com; Stephen Hanna Cc: andreas.steffen@hsr.ch; nea@ietf.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC5793 (2848) The following errata report has been submitted for RFC5793, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D5793&eid=3D2848 -------------------------------------- Type: Technical Reported by: Andreas Steffen > Section: 4.8.1 Original Text ------------- Remediation String (variable length) The Remediation String field MUST contain a UTF-8 [6] encoded string. This string contains human-readable instructions for remediation that MAY be displayed to the user by the Posture Broker Client. NUL termination MUST NOT be included. If a Posture Broker Client receives a Reason String that does contain a NUL termination, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. Corrected Text -------------- Remediation String (variable length) The Remediation String field MUST contain a UTF-8 [6] encoded string. This string contains human-readable instructions for remediation that MAY be displayed to the user by the Posture Broker Client. NUL termination MUST NOT be included. If a Posture Broker Client receives a Remediation String that does contain a NUL termination, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. Notes ----- Copy-and-paste error: Reason String must be changed to Remediation String. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5793 (draft-ietf-nea-pb-tnc-06) -------------------------------------- Title : PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC) Publication Date : March 2010 Author(s) : R. Sahita, S. Hanna, R. Hurst, K. Narayan Category : PROPOSED STANDARD Source : Network Endpoint Assessment Area : Security Stream : IETF Verifying Party : IESG _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From blueroofmusic@gmail.com Thu Jun 30 08:12:07 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179DC11E8189 for ; Thu, 30 Jun 2011 08:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NYwBNuJXLKP for ; Thu, 30 Jun 2011 08:12:05 -0700 (PDT) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id CCA5D11E819C for ; Thu, 30 Jun 2011 08:12:01 -0700 (PDT) Received: by fxe4 with SMTP id 4so2976165fxe.27 for ; Thu, 30 Jun 2011 08:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sdoG48nqRrV+GVvBkABzco4CsE+hDp8/HOFYgynzw0E=; b=dCw8veS/psDJyOF95BgE1wknnMcEX173rsx5Qtq6dMrdRCexD1eO2QTBeWCEDpB1zY 7F8ToBbfWIQ5GRKyPVFjTV9sD8fFuhHO9G/brrzSiozVECjp7qhwhzpw7h0Q50V89YDI SFviXlIzkioVfXq/vhUW1Cze2TIPYUyCUu3KM= MIME-Version: 1.0 Received: by 10.223.73.133 with SMTP id q5mr3185446faj.127.1309446720694; Thu, 30 Jun 2011 08:12:00 -0700 (PDT) Received: by 10.223.17.154 with HTTP; Thu, 30 Jun 2011 08:12:00 -0700 (PDT) In-Reply-To: References: <20110628184311.BB71598C4F4@rfc-editor.org> Date: Thu, 30 Jun 2011 11:12:00 -0400 Message-ID: From: Ira McDonald To: Stephen Hanna , Ira McDonald Content-Type: multipart/alternative; boundary=0015174c1ab8a3a98a04a6ef52f0 Cc: "turners@ieca.com" , "rfc-editor@rfc-editor.org" , "nea@ietf.org" , "Ryan.Hurst@microsoft.com" , "andreas.steffen@hsr.ch" Subject: Re: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:12:07 -0000 --0015174c1ab8a3a98a04a6ef52f0 Content-Type: text/plain; charset=ISO-8859-1 Hi, I agree that the substance of the errata is correct (i.e., a typo from cut-and-paste). I agree that it should be Approved - to avoid interoperability problems. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Co-Chair - IEEE-ISTO PWG IPP WG Chair - TCG Embedded Systems Hardcopy SWG 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 Thu, Jun 30, 2011 at 10:49 AM, Stephen Hanna wrote: > I talked with our ADs about how to handle the errata described > below. We agree that the best thing is to have the NEA WG discuss > it and come to a consensus recommendation on the proper resolution. > If the ADs agree, they'll go ahead and implement our recommendation. > > As one of the editors of RFC 5793, I'd say this errata is pretty > obviously correct. The paragraph in question is talking about the > Remediation String. The one occurrence of Reason String in the text > must have been a copy-paste error in the development of the document. > > The other thing to consider is whether the errata should be Approved > (and therefore published in the RFC Editor's errata database) or > marked Hold For Document Update (in which case it's simply set aside > for a future revision of this RFC). The criterion to be used here is > whether the issue "could cause implementation or deployment problems > or significant confusion". This is a tougher call but I'd say that > it could cause implementation or deployment problems. If an implementer > reads the erroneous text at face value, he/she would skip the mandatory > NUL terminator check for Remediation String. That could result in > interoperability problems since a NEA Server that sends a NUL > terminator on the Remediation String would work fine with one > NEA Client but not with another. So I think the errata should be > Approved. > > Do you agree? Let's see some discussion or simply Agree/Disagree > emails so that we can reach consensus. Susan and I plan to close this > discussion in two weeks (end of July 14) so please respond by then. > > BTW, kudos to Andreas for finding and reporting this problem! > > Thanks, > > Steve > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: Tuesday, June 28, 2011 2:43 PM > > To: Ravi.Sahita@intel.com; Stephen Hanna; Ryan.Hurst@microsoft.com; > > kaushik@cisco.com; stephen.farrell@cs.tcd.ie; turners@ieca.com; > > sethomso@cisco.com; Stephen Hanna > > Cc: andreas.steffen@hsr.ch; nea@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC5793 (2848) > > > > > > The following errata report has been submitted for RFC5793, > > "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network > > Connect (TNC)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=5793&eid=2848 > > > > -------------------------------------- > > Type: Technical > > Reported by: Andreas Steffen > > > > Section: 4.8.1 > > > > Original Text > > ------------- > > Remediation String (variable length) > > > > > > > > The Remediation String field MUST contain a UTF-8 [6] encoded > > > > string. This string contains human-readable instructions for > > > > remediation that MAY be displayed to the user by the Posture > > > > Broker Client. NUL termination MUST NOT be included. If a > > > > Posture Broker Client receives a Reason String that does contain > > a > > > > NUL termination, it MUST respond with a fatal Invalid Parameter > > > > error in a CLOSE batch. > > > > > > > > Corrected Text > > -------------- > > Remediation String (variable length) > > > > > > > > The Remediation String field MUST contain a UTF-8 [6] encoded > > > > string. This string contains human-readable instructions for > > > > remediation that MAY be displayed to the user by the Posture > > > > Broker Client. NUL termination MUST NOT be included. If a > > > > Posture Broker Client receives a Remediation String that does > > contain a > > > > NUL termination, it MUST respond with a fatal Invalid Parameter > > > > error in a CLOSE batch. > > > > Notes > > ----- > > Copy-and-paste error: Reason String must be changed to Remediation > > String. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5793 (draft-ietf-nea-pb-tnc-06) > > -------------------------------------- > > Title : PB-TNC: A Posture Broker (PB) Protocol Compatible > > with Trusted Network Connect (TNC) > > Publication Date : March 2010 > > Author(s) : R. Sahita, S. Hanna, R. Hurst, K. Narayan > > Category : PROPOSED STANDARD > > Source : Network Endpoint Assessment > > Area : Security > > Stream : IETF > > Verifying Party : IESG > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > --0015174c1ab8a3a98a04a6ef52f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I agree that the substance of the errata is correct (i.e., a typ= o
from cut-and-paste).

I agree that it should be Approved - to av= oid interoperability
problems.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Op= en Printing WG
Co-Chair - IEEE-ISTO PWG IPP WG
Chair - TCG Embedded S= ystems Hardcopy SWG
IETF Designated Expert - IPP & Printer 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 Thu, Jun 30, 2011 at 10:49 AM, Stephe= n Hanna <shanna@= juniper.net> wrote:
I talked with our ADs about how to handle the errata described
below. We agree that the best thing is to have the NEA WG discuss
it and come to a consensus recommendation on the proper resolution.
If the ADs agree, they'll go ahead and implement our recommendation.
As one of the editors of RFC 5793, I'd say this errata is pretty
obviously correct. The paragraph in question is talking about the
Remediation String. The one occurrence of Reason String in the text
must have been a copy-paste error in the development of the document.

The other thing to consider is whether the errata should be Approved
(and therefore published in the RFC Editor's errata database) or
marked Hold For Document Update (in which case it's simply set aside for a future revision of this RFC). The criterion to be used here is
whether the issue "could cause implementation or deployment problems or significant confusion". This is a tougher call but I'd say that=
it could cause implementation or deployment problems. If an implementer
reads the erroneous text at face value, he/she would skip the mandatory
NUL terminator check for Remediation String. That could result in
interoperability problems since a NEA Server that sends a NUL
terminator on the Remediation String would work fine with one
NEA Client but not with another. So I think the errata should be
Approved.

Do you agree? Let's see some discussion or simply Agree/Disagree
emails so that we can reach consensus. Susan and I plan to close this
discussion in two weeks (end of July 14) so please respond by then.

BTW, kudos to Andreas for finding and reporting this problem!

Thanks,

Steve

> -----Original Message-----
> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> Sent: Tuesday, June 28, 2011 2:43 PM
> To: Ravi.Sahita@intel.com= ; Stephen Hanna; Ryan.Hurst@mic= rosoft.com;
> kaushik@cisco.com; stephen.farrell@cs.tcd.ie; turners@ieca.com;
> sethomso@cisco.com; Stephen = Hanna
> Cc: andreas.steffen@hsr.ch; nea@ietf.org; rfc-editor@rfc-editor.org
> Subject: [Technical Errata Reported] RFC5793 (2848)
>
>
> The following errata report has been submitted for RFC5793,
> "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted N= etwork
> Connect (TNC)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?r= fc=3D5793&eid=3D2848
>
> --------------------------------------
> Type: Technical
> Reported by: Andreas Steffen <andreas.steffen@hsr.ch>
>
> Section: 4.8.1
>
> Original Text
> -------------
> Remediation String (variable length)
>
>
>
> =A0 =A0 =A0 The Remediation String field MUST contain a UTF-8 [6] enco= ded
>
> =A0 =A0 =A0 string. =A0This string contains human-readable instruction= s for
>
> =A0 =A0 =A0 remediation that MAY be displayed to the user by the Postu= re
>
> =A0 =A0 =A0 Broker Client. =A0NUL termination MUST NOT be included. = =A0If a
>
> =A0 =A0 =A0 Posture Broker Client receives a Reason String that does c= ontain
> a
>
> =A0 =A0 =A0 NUL termination, it MUST respond with a fatal Invalid Para= meter
>
> =A0 =A0 =A0 error in a CLOSE batch.
>
>
>
> Corrected Text
> --------------
> Remediation String (variable length)
>
>
>
> =A0 =A0 =A0 The Remediation String field MUST contain a UTF-8 [6] enco= ded
>
> =A0 =A0 =A0 string. =A0This string contains human-readable instruction= s for
>
> =A0 =A0 =A0 remediation that MAY be displayed to the user by the Postu= re
>
> =A0 =A0 =A0 Broker Client. =A0NUL termination MUST NOT be included. = =A0If a
>
> =A0 =A0 =A0 Posture Broker Client receives a Remediation String that d= oes
> contain a
>
> =A0 =A0 =A0 NUL termination, it MUST respond with a fatal Invalid Para= meter
>
> =A0 =A0 =A0 error in a CLOSE batch.
>
> Notes
> -----
> Copy-and-paste error: Reason String must be changed to Remediation
> String.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary,= please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5793 (draft-ietf-nea-pb-tnc-06)
> --------------------------------------
> Title =A0 =A0 =A0 =A0 =A0 =A0 =A0 : PB-TNC: A Posture Broker (PB) Prot= ocol Compatible
> with Trusted Network Connect (TNC)
> Publication Date =A0 =A0: March 2010
> Author(s) =A0 =A0 =A0 =A0 =A0 : R. Sahita, S. Hanna, R. Hurst, K. Nara= yan
> Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
> Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: Network Endpoint Assessment
> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Security
> Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
> Verifying Party =A0 =A0 : IESG
_______________________________________________
Nea mailing list
Nea@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/nea

--0015174c1ab8a3a98a04a6ef52f0-- From Paul_Sangster@symantec.com Thu Jun 30 08:36:17 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 8A70711E807E for ; Thu, 30 Jun 2011 08:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRhTB29k60Ng for ; Thu, 30 Jun 2011 08:36:16 -0700 (PDT) Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDA311E807F for ; Thu, 30 Jun 2011 08:35:53 -0700 (PDT) X-AuditID: a66201d1-b7b4dae000001b7e-79-4e0c97bae41b Received: from tus1smtintpin02.ges.symantec.com (TUS1SMTINTPIN02.ges.symantec.com [192.168.215.102]) by ecl1mtaoutpex01.symantec.com (Symantec Messaging Gateway) with SMTP id AB.13.07038.AB79C0E4; Thu, 30 Jun 2011 11:35:22 -0400 (EDT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1smtintpin02.ges.symantec.com with esmtp (Exim 4.72) (envelope-from ) id 1QcJGz-0000rS-3j; Thu, 30 Jun 2011 08:35:22 -0700 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Thu, 30 Jun 2011 08:35:21 -0700 From: Paul Sangster To: Stephen Hanna , "nea@ietf.org" Date: Thu, 30 Jun 2011 08:35:16 -0700 Thread-Topic: Seeking Consensus on Errata 2848 Against RFC 5793 Thread-Index: Acw1wz3kfWSnByd6SqimotbIl/Y2+gBTYrUQAAp/FdA= Message-ID: <6E79D623502C70419A9EAB18E4D274252A69CE3D70@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <20110628184311.BB71598C4F4@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsVyYMX1NN1d03n8DG5tMrX4/Vfe4vPbCoum /V/ZLJb9bmSxeHzuFLPFjnMTWBzYPBpmPmL3uDPnA6vHkiU/mTyuN11l92jd8Zfdo6HtGGsA WxSXTUpqTmZZapG+XQJXxs1Du5kKfutVnDl5mrWB8aZKFyMnh4SAiUTT65/sELaYxIV769m6 GLk4hATeMEq8a9/ICOG8ZpR4f24hE4SzilHiU28/K0gLm4CBxM4jp8DaRQRcJeZ87gDrYBa4 wCix+9JBZpAEi4CqxM35e8EahAXsJPqnvGCBaLCXmLsMZB+IbSXx50wzmM0rECWxcvNPMFtI oFKi+e8CsDmcAj4SF2YfAbMZgW79fmoNE4jNLCAucevJfCaIHwQkluw5zwxhi0q8fPyPFaJe VOJO+3pGiHodiQW7P7FB2NoSyxa+ZobYKyhxcuYTlgmM4rOQjJ2FpGUWkpZZSFoWMLKsYpRJ Tc4xzC1JzC8tKUitMDDUK67MTQTGbLJecn7uJkZg3C5LYry4g/HCYd1DjAIcjEo8vDe7ePyE WBPLgCoPMUpwMCuJ8K6qBgrxpiRWVqUW5ccXleakFh9ilOZgURLnVfjL6ickkJ5YkpqdmlqQ WgSTZeLglGpgFF33/NXkmvMnlZfM65HX7n3lL6yeoj9l8ducRKs9iy9G3D7C+bVDcbogZ8a3 0yc9ff+d+hors++radjd/t99a68lnfjO5Ne49W7+zcpteufFKy7Vf/b2X6A1k/fchCXhffWL Zs5VsDmz73+Y11aG1287zikUbEysU+dT+vZmhvI+TbPfUwznuSixFGckGmoxFxUnAgCQRLrt 1wIAAA== Cc: "turners@ieca.com" , "rfc-editor@rfc-editor.org" , "Ryan.Hurst@microsoft.com" , "andreas.steffen@hsr.ch" Subject: Re: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 15:36:17 -0000 I agree that the proposed change is correct. I think it is harder to say w= hether this spec bug would cause interoperability problems if not fixed sin= ce its just about how the client handles (errors out) reception of a string= without the NUL. Is there an IETF admin burden to managing the errata database that caused t= heir providing criteria on when something should go into the database vs ju= st holding the comment for update? I'd personally prefer to see it go into= the errata database but don't believe it's clear whether it meets the crit= eria listed. > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Thursday, June 30, 2011 7:49 AM > To: nea@ietf.org > Cc: Ryan.Hurst@microsoft.com; andreas.steffen@hsr.ch; turners@ieca.com; > rfc-editor@rfc-editor.org > Subject: [Nea] Seeking Consensus on Errata 2848 Against RFC 5793 >=20 > I talked with our ADs about how to handle the errata described > below. We agree that the best thing is to have the NEA WG discuss > it and come to a consensus recommendation on the proper resolution. > If the ADs agree, they'll go ahead and implement our recommendation. >=20 > As one of the editors of RFC 5793, I'd say this errata is pretty > obviously correct. The paragraph in question is talking about the > Remediation String. The one occurrence of Reason String in the text > must have been a copy-paste error in the development of the document. >=20 > The other thing to consider is whether the errata should be Approved > (and therefore published in the RFC Editor's errata database) or > marked Hold For Document Update (in which case it's simply set aside > for a future revision of this RFC). The criterion to be used here is > whether the issue "could cause implementation or deployment problems > or significant confusion". This is a tougher call but I'd say that > it could cause implementation or deployment problems. If an implementer > reads the erroneous text at face value, he/she would skip the mandatory > NUL terminator check for Remediation String. That could result in > interoperability problems since a NEA Server that sends a NUL > terminator on the Remediation String would work fine with one > NEA Client but not with another. So I think the errata should be > Approved. >=20 > Do you agree? Let's see some discussion or simply Agree/Disagree > emails so that we can reach consensus. Susan and I plan to close this > discussion in two weeks (end of July 14) so please respond by then. >=20 > BTW, kudos to Andreas for finding and reporting this problem! >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: Tuesday, June 28, 2011 2:43 PM > > To: Ravi.Sahita@intel.com; Stephen Hanna; Ryan.Hurst@microsoft.com; > > kaushik@cisco.com; stephen.farrell@cs.tcd.ie; turners@ieca.com; > > sethomso@cisco.com; Stephen Hanna > > Cc: andreas.steffen@hsr.ch; nea@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC5793 (2848) > > > > > > The following errata report has been submitted for RFC5793, > > "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted > Network > > Connect (TNC)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D5793&eid=3D2848 > > > > -------------------------------------- > > Type: Technical > > Reported by: Andreas Steffen > > > > Section: 4.8.1 > > > > Original Text > > ------------- > > Remediation String (variable length) > > > > > > > > The Remediation String field MUST contain a UTF-8 [6] encoded > > > > string. This string contains human-readable instructions for > > > > remediation that MAY be displayed to the user by the Posture > > > > Broker Client. NUL termination MUST NOT be included. If a > > > > Posture Broker Client receives a Reason String that does > contain > > a > > > > NUL termination, it MUST respond with a fatal Invalid Parameter > > > > error in a CLOSE batch. > > > > > > > > Corrected Text > > -------------- > > Remediation String (variable length) > > > > > > > > The Remediation String field MUST contain a UTF-8 [6] encoded > > > > string. This string contains human-readable instructions for > > > > remediation that MAY be displayed to the user by the Posture > > > > Broker Client. NUL termination MUST NOT be included. If a > > > > Posture Broker Client receives a Remediation String that does > > contain a > > > > NUL termination, it MUST respond with a fatal Invalid Parameter > > > > error in a CLOSE batch. > > > > Notes > > ----- > > Copy-and-paste error: Reason String must be changed to Remediation > > String. > > > > Instructions: > > ------------- > > This errata is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party (IESG) > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5793 (draft-ietf-nea-pb-tnc-06) > > -------------------------------------- > > Title : PB-TNC: A Posture Broker (PB) Protocol > Compatible > > with Trusted Network Connect (TNC) > > Publication Date : March 2010 > > Author(s) : R. Sahita, S. Hanna, R. Hurst, K. Narayan > > Category : PROPOSED STANDARD > > Source : Network Endpoint Assessment > > Area : Security > > Stream : IETF > > Verifying Party : IESG > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From sethomso@cisco.com Thu Jun 30 15:25:23 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEC711E812E for ; Thu, 30 Jun 2011 15:25:23 -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=[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 faKEZ8CkqOUu for ; Thu, 30 Jun 2011 15:25:22 -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 7499B11E8101 for ; Thu, 30 Jun 2011 15:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=672; q=dns/txt; s=iport; t=1309472722; x=1310682322; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=99b3Ud/iZM7waORrlUtrAH28CAjNEGx2dtnij22QBYU=; b=FvjvTmkVErfILEUZtlhyHDmb0764CGjFu0+0pRcgPBswrJhwDr0A9sr2 y5O4M1Hnyn3MN5iTccNZ1kbWEJbm3qrcuB3BHWDAv2eZ5Upuwb7MU0H8y 0waM4jharDN27HxBDKJTj9dOC1934Ck5y1bbrO76wruue0lU9ZAEGNgve I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwHALf2DE6tJXHA/2dsb2JhbABSmGyOcXeofYEinWWGMQSHQI9ui00 X-IronPort-AV: E=Sophos;i="4.65,454,1304294400"; d="scan'208";a="238870735" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rtp-iport-2.cisco.com with ESMTP; 30 Jun 2011 22:25:21 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p5UMPLGu010152 for ; Thu, 30 Jun 2011 22:25:21 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 17:25:21 -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, 30 Jun 2011 17:25:18 -0500 Message-ID: <6065F7697E427240893C1B5CF41828963DD9AC@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft NEA WG agenda for IETF 81 Thread-Index: Acw3dJdK9Ef8s9JxTvadDkdDpEIqZA== From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 30 Jun 2011 22:25:21.0286 (UTC) FILETIME=[99328260:01CC3774] Subject: [Nea] Draft NEA WG agenda for IETF 81 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, 30 Jun 2011 22:25:23 -0000 Below is the draft agenda for meeting in Quebec City. Please send any other agenda topics to Steve and me. Thanks Susan ---------------- Draft Agenda for NEA WG Meeting at IETF 81 Currently Scheduled For July 27, 2011 1300-1500 EDT 1300 Administrivia Jabber & Minute scribes Agenda bashing 1305 NEA Reference Model 1310 WG Status 1315 Discuss and Resolve Open PT-TLS Comments http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-00.txt 1400 Discuss and Resolve EAP vs. TLVs for L2 PT 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 1500 Adjourn From sethomso@cisco.com Thu Jun 30 15:26:33 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 40D4911E818F for ; Thu, 30 Jun 2011 15:26:33 -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=[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 tUAvEBxwX1z8 for ; Thu, 30 Jun 2011 15:26:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfa.amsl.com (Postfix) with ESMTP id C24C911E8101 for ; Thu, 30 Jun 2011 15:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=1869; q=dns/txt; s=iport; t=1309472792; x=1310682392; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=9vHEnhpatUYnMe/r1rmZnBhkZDoZ2ZGrw/tRcHKybss=; b=Y6C1BHsHeoIQuX+TKjscyWRqHDaUpbgALqu+Oy2SthxzJrLlUWewya/a wM/2JJrH6ktOlbv2d4KlwrviLID0rSkD3svqzfZ8PWWnKO+xoBerIJDB8 hiETk9+LCwicR3Ij3Ddgdu2w1LvSWMK16Poo2xDd5jAQuSYcJ3E+7OXaw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngBAKD3DE6tJXG+/2dsb2JhbABSmCpCjnF3qQKBIp1lhjEEh0CPbotN X-IronPort-AV: E=Sophos;i="4.65,454,1304294400"; d="scan'208";a="473095061" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by sj-iport-1.cisco.com with ESMTP; 30 Jun 2011 22:26:31 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p5UMQVMk009394 for ; Thu, 30 Jun 2011 22:26:31 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 17:26:31 -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, 30 Jun 2011 17:26:30 -0500 Message-ID: <6065F7697E427240893C1B5CF41828963DD9AD@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Please REVIEW PT-TLS I-D Thread-Index: Acwp6XsBXJ/RwEpdTAi+Sna+HWyA3ANg2C1gAAADjbA= From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 30 Jun 2011 22:26:31.0119 (UTC) FILETIME=[C2D22DF0:01CC3774] Subject: [Nea] Please REVIEW PT-TLS I-D X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 22:26:33 -0000 This is a call for comments on the NEA working group document: http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-00.txt Please take the time to review the document and provide comments to the NEA mailing list prior to the IETF meeting (by Fri Jul 22).=20 This will allow us to address outstanding issues at the meeting in Quebec City, and revise the document in preparation for a WG Last Call in August. Thanks Susan -----Original Message----- From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, June 13, 2011 12:45 PM To: i-d-announce@ietf.org Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-tls-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Endpoint Assessment Working Group of the IETF. Title : PT-TLS: A Posture Transport (PT) Protocol Based on Transport Layer Security (TLS) Author(s) : Paul Sangster Nancy Cam-Winget Joseph Salowey Filename : draft-ietf-nea-pt-tls-00.txt Pages : 49 Date : 2011-06-13 This document specifies PT-TLS, a Posture Transport (PT) protocol that carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-00.txt _______________________________________________ Nea mailing list Nea@ietf.org https://www.ietf.org/mailman/listinfo/nea From sethomso@cisco.com Thu Jun 30 15:31:09 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 E9AB111E8101 for ; Thu, 30 Jun 2011 15:31:09 -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=[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 Iq3nRP4qfgnr for ; Thu, 30 Jun 2011 15:31:09 -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 3844111E80B6 for ; Thu, 30 Jun 2011 15:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=1123; q=dns/txt; s=iport; t=1309473069; x=1310682669; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=bUJ6d6ROw64sIrcBcsN0/pddU7/g7ShYSyv0eIHA960=; b=EZiC5/9kzdcUJ2tdfgxE9XklyJCihiXn3ZEUMk92++9fBgm7v1FU9TVt 1f8LbYW1BzkUJz1UZkRddCcUrtwncAKL7uU+osTGC4GdYN7TAqTx4ccIK TMgdL4p5HpvQN89rG2dP6IQrbTpLYKpg28nCNpxt7whpZF3q9FRNcZRN4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwHAN73DE6tJV2c/2dsb2JhbABSmGyOcXepCYEinWWGMQSHQI9ui00 X-IronPort-AV: E=Sophos;i="4.65,454,1304294400"; d="scan'208";a="238871180" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 30 Jun 2011 22:31:08 +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 p5UMV8RE007174 for ; Thu, 30 Jun 2011 22:31:08 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 30 Jun 2011 17:31:08 -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, 30 Jun 2011 17:31:07 -0500 Message-ID: <6065F7697E427240893C1B5CF41828963DD9AE@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CALL for COMMENTS on EAP PT approaches Thread-Index: Acw3dWecgPzMKxGHRLuTrVuREyOhaQ== From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 30 Jun 2011 22:31:08.0142 (UTC) FILETIME=[67F088E0:01CC3775] Subject: [Nea] CALL for COMMENTS on EAP PT approaches X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2011 22:31:10 -0000 One of the outstanding items in the NEA WG is to come to consensus on whether to use EAP method or TLV for carrying NEA data in an EAP-based transport.=20 Steve Hanna has initiated a thread on this topic on the mailing list to which some have responded (see pointer below to email thread and to meeting minutes for summary of discussion at IETF 80). We need more input from the WG to make a decision. Please review the pros and cons laid out in the thread and provide your input. Feedback may include any considerations that you think might be missing from the discussion, as well how you would weigh the characteristics of the two approaches. The deadline for making a decision is by the July IETF. If we do not, our AD has "offered" to make the decision for us! So please take the time to post your views. I think it would reflect poorly on the WG if we are unable to come to consensus ourselves. Thanks Susan Email Thread starts here: http://www.ietf.org/mail-archive/web/nea/current/msg01120.html Meeting minutes from IETF 80: http://tools.ietf.org/wg/nea/minutes?item=3Dminutes80.html