From sethomso@cisco.com Wed Nov 2 14:50: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 DC93F1F0C63 for ; Wed, 2 Nov 2011 14:50:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9SZCEkLk1+u for ; Wed, 2 Nov 2011 14:50:33 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 151181F0C5D for ; Wed, 2 Nov 2011 14:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=773; q=dns/txt; s=iport; t=1320270631; x=1321480231; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=2RCOCuy+N1BK0yf7Y82JmLPu/EVbVHYvGxaUb10NBWc=; b=Qfoxttmz/Jb3xQKQ/LSxeiAMwdF0aNQY5XXL9nz+68DdnINXslMjCxYi J64ys9cLdVS/Ii5B4+ikIrL2oa808m7DiBe+VaLmt6B/sIynUP0j1X3/8 rrXYHf0PUwZLjnEMMB+lU0ccFl7dYlcmyh4TuIR8qrDMFwHEcuEJK/Si2 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEGABe6sU6tJV2b/2dsb2JhbABEmjmPOoEFgXQBBBIBJwIBTgEcgQoBBBMJGYdolRSBJgGef4kQBJQUhTqMRw X-IronPort-AV: E=Sophos;i="4.69,446,1315180800"; d="scan'208";a="32940708" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 02 Nov 2011 21:50:30 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA2LodH9029331 for ; Wed, 2 Nov 2011 21:50:39 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); Wed, 2 Nov 2011 16:50:30 -0500 Received: from 10.116.64.105 ([10.116.64.105]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 2 Nov 2011 21:50:30 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Wed, 02 Nov 2011 17:50:29 -0400 From: Susan Thomson To: Message-ID: Thread-Topic: Draft NEA WG agenda for IETF 82 Thread-Index: AcyZqW+7MssNE3+d606tSxyRXsuYpg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Nov 2011 21:50:30.0741 (UTC) FILETIME=[70C56850:01CC99A9] Subject: [Nea] Draft NEA WG agenda for IETF 82 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 21:50:34 -0000 Below is the draft agenda for IETF in Taiwan. Please let the chairs know of any proposed additions. Thanks Susan -------------- Agenda for IETF 82 NEA WG meeting ================================= Date: Thursday, Nov 17 2011 Time: 0900-1130 CST (GMT+8) WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 0900 Administrivia Blue Sheets Jabber & Minute scribes Agenda bashing 0905 WG Status 0910 NEA Reference Model 0915 Discuss and Resolve WGLC PT-TLS Comments http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-01.txt 1000 Discuss and Resolve PT-EAP Issues http://www.ietf.org/id/draft-ietf-nea-pt-eap-00.txt 1115 Next Steps 1130 Adjourn From latze@angry-red-pla.net Fri Nov 4 01:35: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 7029721F8C10 for ; Fri, 4 Nov 2011 01:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0ufUOZchHR5 for ; Fri, 4 Nov 2011 01:35:49 -0700 (PDT) Received: from thuvia.angry-red-pla.net (thuvia.angry-red-pla.net [83.169.33.217]) by ietfa.amsl.com (Postfix) with ESMTP id 78F2321F8C0E for ; Fri, 4 Nov 2011 01:35:48 -0700 (PDT) Received: from 55-186.106-92.cust.bluewin.ch ([92.106.186.55] helo=[192.168.1.178]) by thuvia.angry-red-pla.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RMFFa-0006q2-Gp for nea@ietf.org; Fri, 04 Nov 2011 09:35:47 +0100 Message-ID: <4EB3A450.8090301@angry-red-pla.net> Date: Fri, 04 Nov 2011 09:37:36 +0100 From: Carolin Latze User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111004 Icedove/3.0.11 MIME-Version: 1.0 To: nea@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Nea] Extending WG Last Call on 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: Fri, 04 Nov 2011 08:35:51 -0000 I did not read the complete draft again, but checked it mainly against my last comments: - section 3.1.1: would it make sense to specify how to keep the TLS session alive? I think it might be helpful to ensure interoperability - section 3.6, type 8: maybe add "[RFC5793]" so that readers know where to find the PB-TNC spec - section 3.9: error code 6 exists twice (SASL Mech Error & Auth Need) regards Carolin On 10/31/2011 03:58 AM, Stephen Hanna wrote: > No comments were received during this WGLC. That makes it > hard for the WG chairs to determine what the consensus of > the WG is with respect to this document. We have agreed to > extend this WGLC until 5 PM PDT on next Friday, November 5. > > Please take this opportunity to review this document and > provide your comments, even brief ones such as "fine work" > or "needs more details in section 5". > > Thanks, > > Steve > > >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of >> Susan Thomson >> Sent: Wednesday, September 28, 2011 6:24 PM >> To: nea@ietf.org >> Subject: [Nea] Starting WG Last Call on PT-TLS I-D >> >> A new version of the PT-TLS I-D has recently been posted based on >> comments >> received at the last IETF meeting. >> >> This message is a WG Last Call for comments on this draft: >> >> http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-01.txt >> >> >> The Last Call period will run for 4 weeks ending on Wednesday Oct 26 at >> 5pm >> PT. >> >> Please send your comments and suggestions for updated text to the NEA >> WG >> mailing list by the above date. Issues will be addressed on the mailing >> list >> and at the next IETF meeting in November. >> >> Please take the time to review the I-D carefully and suggest >> improvements. >> >> Thanks >> Susan >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea >> > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > From sethomso@cisco.com Fri Nov 4 15:56:26 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 1C04221F8481 for ; Fri, 4 Nov 2011 15:56:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq9mWWwOaSy2 for ; Fri, 4 Nov 2011 15:56:25 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCA521F8480 for ; Fri, 4 Nov 2011 15:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=1326; q=dns/txt; s=iport; t=1320447385; x=1321656985; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=TjvhPfkEctcW5RqJ0bQtbKRaovKSJwK54FNSpCmyw+w=; b=kcahA08gw2u7yKXCMU4kVVFuwp892W7H7n8hiOClcp+iUuGcEGJxIm44 8zJhBv8ur80+bCGGTUF+4Xkz8QQOCENKVkltqOAcCB/jg59uaB/xpOkc/ gpCnda0c4Dg78ezObX8DsnAhDG6Dcoxy9d+iczW0FwCMxPLx5L1S7/RQ5 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKxstE6tJXG9/2dsb2JhbABEqgaBBYFyAQEBBBIBFBMCAU4BCA6BDwEBBAE0n2ABnjyJKwSUHIU6jEg X-IronPort-AV: E=Sophos;i="4.69,457,1315180800"; d="scan'208";a="33540486" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 04 Nov 2011 22:56:25 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA4MuNLE009280; Fri, 4 Nov 2011 22:56:23 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 17:56:23 -0500 Received: from 10.116.64.105 ([10.116.64.105]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Nov 2011 22:56:22 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Fri, 04 Nov 2011 18:56:22 -0400 From: Susan Thomson To: Stephen Hanna , "nea@ietf.org" Message-ID: Thread-Topic: [Nea] Extending WG Last Call on PT-TLS I-D Thread-Index: Acx+LUMGWNW3Rd1P1kC7DWASTuuBNgZSy8LgAPMhq48= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Nov 2011 22:56:23.0197 (UTC) FILETIME=[F971D4D0:01CC9B44] Subject: Re: [Nea] Extending WG Last Call on 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: Fri, 04 Nov 2011 22:56:26 -0000 A few editorial comments below. Thanks Susan ------------------ Section 1.1: Remove last sentence. Don't think it is needed anymore. Section 2.1: First sentence: EAP is not necessarily run directly over link layer. Hence, for generality, remove "link layer oriented bindings such as" from first sentence. Bullet list, first item: While PT-TLS is full duplex, PB-TNC does not take advantage of this except for async initiation of posture exchanges. Correct? If so, you may want to make this clearer. Section 3.3: First sentence: Do you mean Posture Broker *Client* here? Section 3.4.2.2 First sentence: "it is" -> it's 2nd para: First few sentence repetitively uses the word "client". In one case, I think you mean PT Server, and in other cases, I think one can drop referral to authentication "of the client" without loss of clarity. Section 3.6 Message Type 10: In description, do you mean "recipients of type *10* or higher ..."? The message type IDs are different from that listed in Section 6.2. I think Section 6.2 needs to be corrected? Section 3.7 Last sentence: Change the SHOULD NOT to a MUST NOT? Section 3.8.3 Ist para, 2nd last sentence: Typo "if it believes *it* is" Section 3.9 Two error messages with code #6 Section 6.2: See comment on section 3.6. From ncamwing@cisco.com Tue Nov 8 14:18:24 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 0685E1F0C6F for ; Tue, 8 Nov 2011 14:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id frOLrYeu+e77 for ; Tue, 8 Nov 2011 14:18:22 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 319861F0C69 for ; Tue, 8 Nov 2011 14:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ncamwing@cisco.com; l=6537; q=dns/txt; s=iport; t=1320790702; x=1322000302; h=date:subject:from:to:message-id:mime-version; bh=M58T3VOKLECbrPpvuoo5IDLNtd9LcfvvpdCAmIX2n04=; b=P9wbdxQD/2o2BNUluUnrGGWVZ1h2ZAWOwjRTH4NrDlaGcTXqif+Wh85l JGMr48bhrPgVEHJxWDdLsIhANQDej5HOddGvNZSCRwA88gkiT3YDH7400 8ffSgsLkttPHmsfwZKO2Wc6GlYzJqAwa506pHgNYOx4YQfp9Zv5bOz+JT Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFANSpuU6rRDoJ/2dsb2JhbABDgk2mXHiBBYF0AQQSASpOARp9DwEENZ9pgSYBnm6JLQSHWjGMFoU6jFQ X-IronPort-AV: E=Sophos;i="4.69,479,1315180800"; d="scan'208,217";a="13063310" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 08 Nov 2011 22:18:22 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA8MILeh003988 for ; Tue, 8 Nov 2011 22:18:21 GMT Received: from xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 14:18:21 -0800 Received: from 10.21.65.158 ([10.21.65.158]) by xmb-sjc-21e.amer.cisco.com ([171.70.151.156]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Nov 2011 22:18:21 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Tue, 08 Nov 2011 14:18:01 -0700 From: Nancy Cam-Winget To: Message-ID: Thread-Topic: Comments on nea-pt-eap-00 draft Thread-Index: AcyeZEbh/laNE/VSxE2AwMQdfkWLWQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3403606681_34940686" X-OriginalArrivalTime: 08 Nov 2011 22:18:21.0743 (UTC) FILETIME=[533E93F0:01CC9E64] Subject: [Nea] Comments on nea-pt-eap-00 draft X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 22:18:24 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3403606681_34940686 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi, Here is an initial set of comments against the first version of the PT-EAP draft: > =80 PT-EAP defines the standalone method for carrying NEA data and speci= fies > its bounds and usage to an EAP tunnel method. As such, I recommend that = the > draft stick to naming this method PT-EAP (vs. The use of both PT-EAP and > PT-TNC) >=20 > =80 Update the abstract to: > This document specifies PT-EAP, an EAP based Posture Transport (PT) proto= col > designed to be used only inside an EAP tunnel method. As such, the docum= ent > also describes the intended applicability of PT-EAP as well as the evalua= tion > against the requirements defined in the NEA Requirements and PB-TNC > specifications.=20 >=20 > =80 Introduction update the first sentence to: > This document specifies PT-EAP, and EAP based Posture Transport (PT) prot= ocol > protected by a TLS based tunnel established by an EAP tunnel method. >=20 > =80 2nd paragraph of Introduction should be updated to: > The PT protocol in the NEA architecture is responsible for transporting P= B-TNC > batches (often containing PA-TNC [3] attributes) across the network betwe= en > the NEA Client and NEA Server. The PT protocol must be protected by an o= uter > TLS-based tunnel to ensure the exchanged messages are protected from a va= riety > of threats from hostile intermediaries. >=20 > =80 To be consistent with a single reference of the inner method, my > suggestion is to remove the 5th and 6th paragraph and replace the entire = 4th > paragraph with: >=20 > PT-EAP is an inner EAP method designed to be used under a protected tunne= l > such as EAP-FAST and EAP-TTLS. >=20 > =80 Given proposal to just focus on inner method, replace all instances = of > PT-TNC with PT-EAP >=20 > =80 Section 1.1 remove TNC reference (e.g. the last sentence of the > paragraph) >=20 > =80 Section 3.1: 4th paragraph, 2nd sentence seems to be a non sequitur, > suggest to remove it (e.g. the sentence reading: > =B2Some EAP tunnel methods may provide explicit confirmation of inner metho= d > success; others may not. This is out of scope for the EAP-TNC method.=B2) >=20 > =80 Section 3.4: as NEA has changed the behavior of the method, it merit= s its > own type and thus should be a TBD. >=20 > =80 Section 4: language to enforce use on within protected tunnel should= be > used, suggest wording to: =B3is designed and MUST run inside an EAP tunnel > method=B2 Thanks, Nancy >=20 --B_3403606681_34940686 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Comments on nea-pt-eap-00 draft Hi,

Here is an initial set of comments against the first version of the PT-EAP = draft:

•    PT-EAP defines th= e standalone method for carrying NEA data and specifies its bounds and usage= to an EAP tunnel method.  As such, I recommend that the draft stick to= naming this method PT-EAP (vs. The use of both PT-EAP and PT-TNC)

•    Update the abstract to:
This document specifies PT-EAP, an EAP based Posture Transport (PT) prot= ocol designed to be used only inside an EAP tunnel method.  As such, th= e document also describes the intended applicability of PT-EAP as well as th= e evaluation against the requirements defined in the NEA Requirements and PB= -TNC specifications.

•    Introduction update the first sentence to: This document specifies PT-EAP, and EAP based Posture Transport (PT) pro= tocol protected by a TLS based tunnel established by an EAP tunnel method. &= nbsp;

•    2nd paragraph of Introduction should be updat= ed to:
The PT protocol in the NEA architecture is responsible for transporting = PB-TNC batches (often containing PA-TNC [3] attributes) across the network b= etween the NEA Client and NEA Server.  The PT protocol must be protecte= d by an outer TLS-based tunnel to ensure the exchanged messages are protecte= d from a variety of threats from hostile intermediaries.

•    To be consistent with a single reference of t= he inner method,  my suggestion is to remove the 5th and 6th paragraph = and replace the entire 4th paragraph with:

PT-EAP is an inner EAP method designed to be used under a protected tunn= el such as EAP-FAST and EAP-TTLS.  

•    Given proposal to just focus on inner method,= replace all instances of PT-TNC with PT-EAP

•    Section 1.1 remove TNC reference (e.g. the las= t sentence of the paragraph)

•    Section 3.1: 4th paragraph, 2nd sentence seem= s to be a non sequitur, suggest to remove it (e.g. the sentence reading:
”Some EAP tunnel methods may provide explicit confirmation of inne= r method success; others may not.  This is out of scope for the EAP-TNC= method.”)

•    Section 3.4: as NEA has changed the behavi= or of the method, it merits its own type and thus should be a TBD.

•    Section 4: language to enforce use on within = protected tunnel should be used, suggest wording to: “is designed and = MUST run inside an EAP tunnel method”

Thanks, Nancy
<= SPAN STYLE=3D'font-size:11pt'>
--B_3403606681_34940686-- From shanna@juniper.net Sat Nov 12 05:06:58 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 43D7821F8494 for ; Sat, 12 Nov 2011 05:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.057 X-Spam-Level: X-Spam-Status: No, score=-106.057 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAcwvpuvHCSb for ; Sat, 12 Nov 2011 05:06:57 -0800 (PST) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 9269B21F8493 for ; Sat, 12 Nov 2011 05:06:57 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTr5vavo45dLQx2XhwSF42P6BdBxvLJXr@postini.com; Sat, 12 Nov 2011 05:06:57 PST Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 12 Nov 2011 05:02:44 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Sat, 12 Nov 2011 08:02:43 -0500 From: Stephen Hanna To: "nea@ietf.org" Date: Sat, 12 Nov 2011 08:02:40 -0500 Thread-Topic: WGLC Results for PT-TLS I-D Thread-Index: Acx+LUMGWNW3Rd1P1kC7DWASTuuBNgZSy8LgAnCdAAA= Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Nea] WGLC Results for 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: Sat, 12 Nov 2011 13:06:58 -0000 Susan and I have reviewed the WGLC results for PT-TLS. Although only two responses were received, both were generally positive on the document with only minor comments. The issue of keepalives and the question of SHOULD NOT vs. MUST NOT in section 3.7 seem to be the=20 only substantive comments. We have asked the document editors to prepare a presentation for IETF 82 and an email to the list summarizing the issues raised during WGLC and providing proposed resolutions. Once these issues have been resolved in the WG, the document editors will post a new version of the draft which can go through a quick WGLC if substantive changes were made. Assuming WG consensus is reached, we will then submit the document to the IESG. Thanks, Steve From shanna@juniper.net Mon Nov 14 02:34:56 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 6FC4C11E80C6 for ; Mon, 14 Nov 2011 02:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.117 X-Spam-Level: X-Spam-Status: No, score=-106.117 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yimk24v5z29J for ; Mon, 14 Nov 2011 02:34:54 -0800 (PST) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2DF11E80A0 for ; Mon, 14 Nov 2011 02:34:52 -0800 (PST) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTsDuzLoxfpZ4EWjg3E/2CIwWiyTJevu/@postini.com; Mon, 14 Nov 2011 02:34:53 PST Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Nov 2011 02:27:14 -0800 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Mon, 14 Nov 2011 05:27:13 -0500 From: Stephen Hanna To: Nancy Cam-Winget , "nea@ietf.org" Date: Mon, 14 Nov 2011 05:27:11 -0500 Thread-Topic: Comments on nea-pt-eap-00 draft Thread-Index: AcyeZEbh/laNE/VSxE2AwMQdfkWLWQAAE0Lw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_AC6674AB7BC78549BB231821ABF7A9AEB80F73FBEDEMBX01WFjnprn_" MIME-Version: 1.0 Subject: Re: [Nea] Comments on nea-pt-eap-00 draft X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 10:34:56 -0000 --_000_AC6674AB7BC78549BB231821ABF7A9AEB80F73FBEDEMBX01WFjnprn_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for your comments, Nancy. Personally (WG chair hat off), I find them= quite reasonable. However, I do have a few responses: 1) I would like to see the document not require that this protocol be = carried over an outer TLS-based tunnel. I think we should say "an outer TLS= -based tunnel or equivalent protections". There could be times when the out= er tunnel is based on IPsec, for example. 2) There's only one instance of PT-TNC in the document. I think you me= an EAP-TNC where you say PT-TNC. 3) The WG should decide where and how to refer to TCG and TNC. I think= it's valuable to mention that this protocol will be equivalent to the next= version of the corresponding TCG spec: IF-T for Tunneled EAP Methods. What do others think? Thanks, Steve From: nea-bounces@ietf.org [mailto:nea-bounces= @ietf.org] On Behalf Of Nancy Cam-Winget Sent: Tuesday, November 08, 2011 4:18 PM To: nea@ietf.org Subject: [Nea] Comments on nea-pt-eap-00 draft Hi, Here is an initial set of comments against the first version of the PT-EAP = draft: * PT-EAP defines the standalone method for carrying NEA data and specifi= es its bounds and usage to an EAP tunnel method. As such, I recommend that= the draft stick to naming this method PT-EAP (vs. The use of both PT-EAP a= nd PT-TNC) * Update the abstract to: This document specifies PT-EAP, an EAP based Posture Transport (PT) protoco= l designed to be used only inside an EAP tunnel method. As such, the docum= ent also describes the intended applicability of PT-EAP as well as the eval= uation against the requirements defined in the NEA Requirements and PB-TNC = specifications. * Introduction update the first sentence to: This document specifies PT-EAP, and EAP based Posture Transport (PT) protoc= ol protected by a TLS based tunnel established by an EAP tunnel method. * 2nd paragraph of Introduction should be updated to: The PT protocol in the NEA architecture is responsible for transporting PB-= TNC batches (often containing PA-TNC [3] attributes) across the network bet= ween the NEA Client and NEA Server. The PT protocol must be protected by a= n outer TLS-based tunnel to ensure the exchanged messages are protected fro= m a variety of threats from hostile intermediaries. * To be consistent with a single reference of the inner method, my sugg= estion is to remove the 5th and 6th paragraph and replace the entire 4th pa= ragraph with: PT-EAP is an inner EAP method designed to be used under a protected tunnel = such as EAP-FAST and EAP-TTLS. * Given proposal to just focus on inner method, replace all instances of= PT-TNC with PT-EAP * Section 1.1 remove TNC reference (e.g. the last sentence of the paragr= aph) * Section 3.1: 4th paragraph, 2nd sentence seems to be a non sequitur, s= uggest to remove it (e.g. the sentence reading: "Some EAP tunnel methods may provide explicit confirmation of inner method = success; others may not. This is out of scope for the EAP-TNC method.") * Section 3.4: as NEA has changed the behavior of the method, it merits = its own type and thus should be a TBD. * Section 4: language to enforce use on within protected tunnel should b= e used, suggest wording to: "is designed and MUST run inside an EAP tunnel = method" Thanks, Nancy --_000_AC6674AB7BC78549BB231821ABF7A9AEB80F73FBEDEMBX01WFjnprn_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on nea-pt-eap-00 draft</title= ><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Cambria; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {mso-style-priority:99; mso-style-link:"Balloon Text Char"; margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:"Tahoma","sans-serif";} p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {mso-style-priority:34; margin-top:0in; margin-right:0in; margin-bottom:0in; margin-left:.5in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} span.BalloonTextChar {mso-style-name:"Balloon Text Char"; mso-style-priority:99; mso-style-link:"Balloon Text"; font-family:"Tahoma","sans-serif";} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} /* List Definitions */ @list l0 {mso-list-id:984353302; mso-list-type:hybrid; mso-list-template-ids:1234442170 67698705 67698713 67698715 67698703 67698= 713 67698715 67698703 67698713 67698715;} @list l0:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:none; mso-level-number-position:left; text-indent:-.25in;} @list l0:level2 {mso-level-tab-stop:1.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} @list l0:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue vli= nk=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span style=3D'f= ont-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks fo= r your comments, Nancy. Personally (WG chair hat off), I find them quite re= asonable.  However, I do have a few responses:</span><span style=3D'fo= nt-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p= ></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-famil= y:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p clas= s=3DMsoListParagraph style=3D'text-indent:-.25in;mso-list:l0 level1 lfo1'><= ![if !supportLists]><span style=3D'font-size:11.0pt;font-family:"Calibri","= sans-serif";color:#1F497D'><span style=3D'mso-list:Ignore'>1)<span style=3D= 'font:7.0pt "Times New Roman"'>      </span></span= ></span><![endif]><span style=3D'font-size:11.0pt;font-family:"Calibri","sa= ns-serif";color:#1F497D'>I would like to see the document not require that = this protocol be carried over an outer TLS-based tunnel. I think we should = say “an outer TLS-based tunnel or equivalent protections”. Ther= e could be times when the outer tunnel is based on IPsec, for example.<o:p>= </o:p></span></p><p class=3DMsoListParagraph style=3D'text-indent:-.25in;ms= o-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'font-size:11.0pt= ;font-family:"Calibri","sans-serif";color:#1F497D'><span style=3D'mso-list:= Ignore'>2)<span style=3D'font:7.0pt "Times New Roman"'>   &n= bsp;  </span></span></span><![endif]><span style=3D'font-size:11.0pt;f= ont-family:"Calibri","sans-serif";color:#1F497D'>There’s only one ins= tance of PT-TNC in the document. I think you mean EAP-TNC where you say PT-= TNC.<o:p></o:p></span></p><p class=3DMsoListParagraph style=3D'text-indent:= -.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style=3D'font-si= ze:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><span style=3D'= mso-list:Ignore'>3)<span style=3D'font:7.0pt "Times New Roman"'>  = ;    </span></span></span><![endif]><span style=3D'font-size= :11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The WG should dec= ide where and how to refer to TCG and TNC. I think it’s valuable to m= ention that this protocol will be equivalent to the next version of the cor= responding TCG spec: IF-T for Tunneled EAP Methods.<o:p></o:p></span></p><p= class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","s= ans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=3DMsoNormal>= <span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1= F497D'>What do others think?<o:p></o:p></span></p><p class=3DMsoNormal><spa= n style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497= D'><o:p> </o:p></span></p><p class=3DMsoNormal><span style=3D'font-siz= e:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks,<o:p></o:= p></span></p><p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-fami= ly:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p cla= ss=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-= serif";color:#1F497D'>Steve<o:p></o:p></span></p><p class=3DMsoNormal><span= style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D= '><o:p> </o:p></span></p><div style=3D'border:none;border-left:solid b= lue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style=3D'border:none;border-= top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=3DMsoNormal><b>= <span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</s= pan></b><span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'>= <a href=3D"mailto:nea-bounces@ietf.org">nea-bounces@ietf.org</a> [<a href= =3D"mailto:nea-bounces@ietf.org">mailto:nea-bounces@ietf.org</a>] <b>On Beh= alf Of </b>Nancy Cam-Winget<br><b>Sent:</b> Tuesday, November 08, 2011 4:18= PM<br><b>To:</b> <a href=3D"mailto:nea@ietf.org">nea@ietf.org</a><br><b>Su= bject:</b> [Nea] Comments on nea-pt-eap-00 draft<o:p></o:p></span></p></div= ></div><p class=3DMsoNormal><o:p> </o:p></p><p class=3DMsoNormal style= =3D'margin-bottom:12.0pt'><span style=3D'font-size:11.0pt;font-family:"Cali= bri","sans-serif"'>Hi,<br><br>Here is an initial set of comments against th= e first version of the PT-EAP draft:</span><o:p></o:p></p><p class=3DMsoNor= mal><span style=3D'font-size:7.5pt;font-family:Symbol'>• </span><span = style=3D'font-size:7.5pt'> </span><span style=3D'font-size:11.0pt;font= -family:"Calibri","sans-serif"'>  PT-EAP defines the standalone method= for carrying NEA data and specifies its bounds and usage to an EAP tunnel = method.  As such, I recommend that the draft stick to naming this meth= od PT-EAP (vs. The use of both PT-EAP and PT-TNC)<br><br>•  &nbs= p; Update the abstract to:<br><i>This document specifies PT-EAP, an EA= P based Posture Transport (PT) protocol designed to be used only inside an = EAP tunnel method.  As such, the document also describes the intended = applicability of PT-EAP as well as the evaluation against the requirements = defined in the NEA Requirements and PB-TNC specifications. <br><br></i>R= 26;    Introduction update the first sentence to:<br><i>This= document specifies PT-EAP, and EAP based Posture Transport (PT) protocol p= rotected by a TLS based tunnel established by an EAP tunnel method.  <= br><br></i>•    2nd paragraph of Introduction should b= e updated to:<br><i>The PT protocol in the NEA architecture is responsible = for transporting PB-TNC batches (often containing PA-TNC [3] attributes) ac= ross the network between the NEA Client and NEA Server.  The PT protoc= ol must be protected by an outer TLS-based tunnel to ensure the exchanged m= essages are protected from a variety of threats from hostile intermediaries= .<br><br></i>•    To be consistent with a single refer= ence of the inner method,  my suggestion is to remove the 5th and 6th = paragraph and replace the entire 4th paragraph with:<br><br><i>PT-EAP is an= inner EAP method designed to be used under a protected tunnel such as EAP-= FAST and EAP-TTLS.  <br><br></i>•    Given propos= al to just focus on inner method, replace all instances of PT-TNC with PT-E= AP<br><br>•    <i>Section 1.1 remove TNC reference (e.= g. the last sentence of the paragraph)<br><br></i>•    = ;Section 3.1: 4th paragraph, 2nd sentence seems to be a non sequitur, sugge= st to remove it (e.g. the sentence reading:<br><i>”Some EAP tunnel me= thods may provide explicit confirmation of inner method success; others may= not.  This is out of scope for the EAP-TNC method.”)<br><br></i= >•    <i>Section 3.4: as NEA has changed the behavior = of the method, it merits its own type and thus should be a TBD.<br><br></i>= •    Section 4: language to enforce use on within prot= ected tunnel should be used, suggest wording to: “is designed and MUS= T run inside an EAP tunnel method”</span><o:p></o:p></p><p class=3DMs= oNormal><span style=3D'font-size:9.0pt;font-family:"Cambria","serif"'><br><= /span><span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>T= hanks, Nancy</span><o:p></o:p></p><p class=3DMsoNormal><o:p> </o:p></p= ></div></div></body></html>= --_000_AC6674AB7BC78549BB231821ABF7A9AEB80F73FBEDEMBX01WFjnprn_-- From blueroofmusic@gmail.com Mon Nov 14 05:31:12 2011 Return-Path: <blueroofmusic@gmail.com> 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 BC36421F8CC2 for <nea@ietfa.amsl.com>; Mon, 14 Nov 2011 05:31:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.387 X-Spam-Level: X-Spam-Status: No, score=-3.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBIFNoMzZm7J for <nea@ietfa.amsl.com>; Mon, 14 Nov 2011 05:31:10 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id B153F21F8CBB for <nea@ietf.org>; Mon, 14 Nov 2011 05:31:09 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so7272890bkb.31 for <nea@ietf.org>; Mon, 14 Nov 2011 05:31:08 -0800 (PST) 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=hmtMkm1VweVadYj0Np+zt6YEwNneWT+v62PlRUSkwOM=; b=UMdJ6SuW7Y7wooZAExM82ZMZyapKocDQlZFVO5dJhMi8mo97Yd1ZaE3VC4OlCkPOQs Fxz02vipBa6TPatnKY6DLlcgtkqvSPZArl8nAMoJw2BMO9+MxuHfG4jNCu5/+rhPi2p0 FC5BfVG4cEqo8LgvcjKSqazkDTlg3nTkRdnzU= MIME-Version: 1.0 Received: by 10.205.132.17 with SMTP id hs17mr19263747bkc.96.1321277468657; Mon, 14 Nov 2011 05:31:08 -0800 (PST) Received: by 10.223.124.203 with HTTP; Mon, 14 Nov 2011 05:31:08 -0800 (PST) In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AEB80F73FBED@EMBX01-WF.jnpr.net> References: <CADEEA99.17F27%ncamwing@cisco.com> <AC6674AB7BC78549BB231821ABF7A9AEB80F73FBED@EMBX01-WF.jnpr.net> Date: Mon, 14 Nov 2011 08:31:08 -0500 Message-ID: <CAN40gStKM-40y42FS7jvtT_K2wEMSTrqmp4Vf85tS5AgJD0iAw@mail.gmail.com> From: Ira McDonald <blueroofmusic@gmail.com> To: Stephen Hanna <shanna@juniper.net>, Ira McDonald <blueroofmusic@gmail.com> Content-Type: multipart/alternative; boundary=0015175cfb0a2b48bd04b1b1e275 Cc: "nea@ietf.org" <nea@ietf.org> Subject: Re: [Nea] Comments on nea-pt-eap-00 draft X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list <nea.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/nea>, <mailto:nea-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/nea> List-Post: <mailto:nea@ietf.org> List-Help: <mailto:nea-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/nea>, <mailto:nea-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 14 Nov 2011 13:31:12 -0000 --0015175cfb0a2b48bd04b1b1e275 Content-Type: text/plain; charset=ISO-8859-1 Hi I agree with Nancy's and Steve's comments. I do think it's important to highlight that this document is/will be equivalent to the next version of TCG IF-T for Tunneled EAP Methods. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG IPP WG Co-Chair - TCG Trusted Mobility Solutions WG Chair - TCG Embedded Systems Hardcopy SG 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 Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Mon, Nov 14, 2011 at 5:27 AM, Stephen Hanna <shanna@juniper.net> wrote: > Thanks for your comments, Nancy. Personally (WG chair hat off), I find > them quite reasonable. However, I do have a few responses:**** > > ** ** > > **1) **I would like to see the document not require that this > protocol be carried over an outer TLS-based tunnel. I think we should say > "an outer TLS-based tunnel or equivalent protections". There could be times > when the outer tunnel is based on IPsec, for example.**** > > **2) **There's only one instance of PT-TNC in the document. I think > you mean EAP-TNC where you say PT-TNC.**** > > **3) **The WG should decide where and how to refer to TCG and TNC. I > think it's valuable to mention that this protocol will be equivalent to the > next version of the corresponding TCG spec: IF-T for Tunneled EAP Methods. > **** > > ** ** > > What do others think?**** > > ** ** > > Thanks,**** > > ** ** > > Steve**** > > ** ** > > *From:* nea-bounces@ietf.org [mailto:nea-bounces@ietf.org<nea-bounces@ietf.org>] > *On Behalf Of *Nancy Cam-Winget > *Sent:* Tuesday, November 08, 2011 4:18 PM > *To:* nea@ietf.org > *Subject:* [Nea] Comments on nea-pt-eap-00 draft**** > > ** ** > > Hi, > > Here is an initial set of comments against the first version of the PT-EAP > draft:**** > > PT-EAP defines the standalone method for carrying NEA data and > specifies its bounds and usage to an EAP tunnel method. As such, I > recommend that the draft stick to naming this method PT-EAP (vs. The use of > both PT-EAP and PT-TNC) > > * Update the abstract to: > *This document specifies PT-EAP, an EAP based Posture Transport (PT) > protocol designed to be used only inside an EAP tunnel method. As such, > the document also describes the intended applicability of PT-EAP as well as > the evaluation against the requirements defined in the NEA Requirements and > PB-TNC specifications. > > ** Introduction update the first sentence to: > *This document specifies PT-EAP, and EAP based Posture Transport (PT) > protocol protected by a TLS based tunnel established by an EAP tunnel > method. > > ** 2nd paragraph of Introduction should be updated to: > *The PT protocol in the NEA architecture is responsible for transporting > PB-TNC batches (often containing PA-TNC [3] attributes) across the network > between the NEA Client and NEA Server. The PT protocol must be protected > by an outer TLS-based tunnel to ensure the exchanged messages are protected > from a variety of threats from hostile intermediaries. > > ** To be consistent with a single reference of the inner method, my > suggestion is to remove the 5th and 6th paragraph and replace the entire > 4th paragraph with: > > *PT-EAP is an inner EAP method designed to be used under a protected > tunnel such as EAP-FAST and EAP-TTLS. > > ** Given proposal to just focus on inner method, replace all instances > of PT-TNC with PT-EAP > > * *Section 1.1 remove TNC reference (e.g. the last sentence of the > paragraph) > > ** Section 3.1: 4th paragraph, 2nd sentence seems to be a non > sequitur, suggest to remove it (e.g. the sentence reading: > *"Some EAP tunnel methods may provide explicit confirmation of inner > method success; others may not. This is out of scope for the EAP-TNC > method.") > > ** *Section 3.4: as NEA has changed the behavior of the method, it > merits its own type and thus should be a TBD. > > ** Section 4: language to enforce use on within protected tunnel > should be used, suggest wording to: "is designed and MUST run inside an EAP > tunnel method"**** > > > Thanks, Nancy**** > > ** ** > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > > --0015175cfb0a2b48bd04b1b1e275 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi <br><br>I agree with Nancy's and Steve's comments.  I do th= ink it's important<br>to highlight that this document is/will be equiva= lent to the next version<br>of TCG IF-T for Tunneled EAP Methods.<br><br>Ch= eers,<br> - Ira<br><br clear=3D"all">Ira McDonald (Musician / Software Architect)<br>= Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer = Working Group<br>Co-Chair - IEEE-ISTO PWG IPP WG<br>Co-Chair - TCG Trusted = Mobility Solutions WG<br> Chair - TCG Embedded Systems Hardcopy SG<br>IETF Designated Expert - IPP &a= mp; Printer MIB<br>Blue Roof Music/High North Inc<br><a style=3D"color:rgb(= 51, 51, 255)" href=3D"http://sites.google.com/site/blueroofmusic" target=3D= "_blank">http://sites.google.com/site/blueroofmusic</a><br> <a style=3D"color:rgb(102, 0, 204)" href=3D"http://sites.google.com/site/hi= ghnorthinc" target=3D"_blank">http://sites.google.com/site/highnorthinc</a>= <br>mailto:<a href=3D"mailto:blueroofmusic@gmail.com" target=3D"_blank">blu= eroofmusic@gmail.com</a><br> Winter  579 Park Place  Saline, MI  48176  734-944-0094= <br>Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434= <div style=3D"display:inline"></div><div style=3D"display:inline"></div><di= v style=3D"display:inline"></div><div> </div><div></div><div></div><div></div><br> <br><br><div class=3D"gmail_quote">On Mon, Nov 14, 2011 at 5:27 AM, Stephen= Hanna <span dir=3D"ltr"><<a href=3D"mailto:shanna@juniper.net">shanna@j= uniper.net</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div link=3D"blue" vlink=3D"purple" lang=3D"EN-US"><div><p class=3D"MsoNorm= al"><span style=3D"font-size:11.0pt;color:#1F497D">Thanks for your comments= , Nancy. Personally (WG chair hat off), I find them quite reasonable.  = ;However, I do have a few responses:</span><span style=3D"font-size:11.0pt;= color:#1F497D"><u></u><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D"><u></= u> <u></u></span></p><p><u></u><span style=3D"font-size:11.0pt;color:#= 1F497D"><span>1)<span style=3D"font:7.0pt "Times New Roman"">&nbs= p;     </span></span></span><u></u><span style=3D"font-= size:11.0pt;color:#1F497D">I would like to see the document not require tha= t this protocol be carried over an outer TLS-based tunnel. I think we shoul= d say “an outer TLS-based tunnel or equivalent protections”. Th= ere could be times when the outer tunnel is based on IPsec, for example.<u>= </u><u></u></span></p> <p><u></u><span style=3D"font-size:11.0pt;color:#1F497D"><span>2)<span styl= e=3D"font:7.0pt "Times New Roman"">     = </span></span></span><u></u><span style=3D"font-size:11.0pt;color:#1F497D"= >There’s only one instance of PT-TNC in the document. I think you mea= n EAP-TNC where you say PT-TNC.<u></u><u></u></span></p> <p><u></u><span style=3D"font-size:11.0pt;color:#1F497D"><span>3)<span styl= e=3D"font:7.0pt "Times New Roman"">     = </span></span></span><u></u><span style=3D"font-size:11.0pt;color:#1F497D"= >The WG should decide where and how to refer to TCG and TNC. I think it&rsq= uo;s valuable to mention that this protocol will be equivalent to the next = version of the corresponding TCG spec: IF-T for Tunneled EAP Methods.<u></u= ><u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D"><u></= u> <u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:1= 1.0pt;color:#1F497D">What do others think?<u></u><u></u></span></p><p class= =3D"MsoNormal"> <span style=3D"font-size:11.0pt;color:#1F497D"><u></u> <u></u></span><= /p><p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">Th= anks,<u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-si= ze:11.0pt;color:#1F497D"><u></u> <u></u></span></p> <p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;color:#1F497D">Steve= <u></u><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11= .0pt;color:#1F497D"><u></u> <u></u></span></p><div style=3D"border:non= e;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"> <div><div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt= 0in 0in 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:10.0pt">Fr= om:</span></b><span style=3D"font-size:10.0pt"> <a href=3D"mailto:nea-bounc= es@ietf.org" target=3D"_blank">nea-bounces@ietf.org</a> [<a href=3D"mailto:= nea-bounces@ietf.org" target=3D"_blank">mailto:nea-bounces@ietf.org</a>] <b= >On Behalf Of </b>Nancy Cam-Winget<br> <b>Sent:</b> Tuesday, November 08, 2011 4:18 PM<br><b>To:</b> <a href=3D"ma= ilto:nea@ietf.org" target=3D"_blank">nea@ietf.org</a><br><b>Subject:</b> [N= ea] Comments on nea-pt-eap-00 draft<u></u><u></u></span></p></div></div><di= v> <div class=3D"h5"><p class=3D"MsoNormal"><u></u> <u></u></p><p class= =3D"MsoNormal" style=3D"margin-bottom:12.0pt"><span style=3D"font-size:11.0= pt">Hi,<br><br>Here is an initial set of comments against the first version= of the PT-EAP draft:</span><u></u><u></u></p> <p class=3D"MsoNormal"><span style=3D"font-size:7.5pt;font-family:Symbol"> = </span><span style=3D"font-size:7.5pt"> </span><span style=3D"font-si= ze:11.0pt">  PT-EAP defines the standalone method for carrying NEA dat= a and specifies its bounds and usage to an EAP tunnel method.  As such= , I recommend that the draft stick to naming this method PT-EAP (vs. The us= e of both PT-EAP and PT-TNC)<br> <br>•    Update the abstract to:<br><i>This document sp= ecifies PT-EAP, an EAP based Posture Transport (PT) protocol designed to be= used only inside an EAP tunnel method.  As such, the document also de= scribes the intended applicability of PT-EAP as well as the evaluation agai= nst the requirements defined in the NEA Requirements and PB-TNC specificati= ons. <br> <br></i>•    Introduction update the first sentence to:= <br><i>This document specifies PT-EAP, and EAP based Posture Transport (PT)= protocol protected by a TLS based tunnel established by an EAP tunnel meth= od.  <br><br></i>•    2nd paragraph of Introductio= n should be updated to:<br> <i>The PT protocol in the NEA architecture is responsible for transporting = PB-TNC batches (often containing PA-TNC [3] attributes) across the network = between the NEA Client and NEA Server.  The PT protocol must be protec= ted by an outer TLS-based tunnel to ensure the exchanged messages are prote= cted from a variety of threats from hostile intermediaries.<br> <br></i>•    To be consistent with a single reference o= f the inner method,  my suggestion is to remove the 5th and 6th paragr= aph and replace the entire 4th paragraph with:<br><br><i>PT-EAP is an inner= EAP method designed to be used under a protected tunnel such as EAP-FAST a= nd EAP-TTLS.  <br> <br></i>•    Given proposal to just focus on inner meth= od, replace all instances of PT-TNC with PT-EAP<br><br>•   &= nbsp;<i>Section 1.1 remove TNC reference (e.g. the last sentence of the par= agraph)<br><br></i>•    Section 3.1: 4th paragraph, 2nd= sentence seems to be a non sequitur, suggest to remove it (e.g. the senten= ce reading:<br> <i>”Some EAP tunnel methods may provide explicit confirmation of inne= r method success; others may not.  This is out of scope for the EAP-TN= C method.”)<br><br></i>•    <i>Section 3.4: as NE= A has changed the behavior of the method, it merits its own type and thus s= hould be a TBD.<br> <br></i>•    Section 4: language to enforce use on with= in protected tunnel should be used, suggest wording to: “is designed = and MUST run inside an EAP tunnel method”</span><u></u><u></u></p><p = class=3D"MsoNormal"><span style=3D"font-size:9.0pt;font-family:"Cambri= a","serif""><br> </span><span style=3D"font-size:11.0pt">Thanks, Nancy</span><u></u><u></u><= /p><p class=3D"MsoNormal"><u></u> <u></u></p></div></div></div></div><= /div><br>_______________________________________________<br> Nea mailing list<br> <a href=3D"mailto:Nea@ietf.org">Nea@ietf.org</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/nea" target=3D"_blank">htt= ps://www.ietf.org/mailman/listinfo/nea</a><br> <br></blockquote></div><br><div style=3D"visibility: hidden; left: -5000px;= " id=3D"avg_ls_inline_popup"></div> --0015175cfb0a2b48bd04b1b1e275-- From sethomso@cisco.com Mon Nov 14 16:50:30 2011 Return-Path: <sethomso@cisco.com> 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 E81EE21F8E5A for <nea@ietfa.amsl.com>; Mon, 14 Nov 2011 16:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-1tmHDtT-bG for <nea@ietfa.amsl.com>; Mon, 14 Nov 2011 16:50:30 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 693EE21F8E4C for <nea@ietf.org>; Mon, 14 Nov 2011 16:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=1188; q=dns/txt; s=iport; t=1321318230; x=1322527830; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=xxSSSdCcb0QnrcGBV8bbNlCVw6oWfZWW6av4uccJ+C4=; b=eyRLb++B6pNKQF1c01xzARgmVwwnT61NbmgUyh7To69Pgigq6iufwzzk Ehn2sr/y7LhYVYar2MDlld2rxzSTobEKJz9dJr+IKseqIqiGkLEPRsmib ta+6i2bB5zq0Ev7gx6dRBWWzWLOfqSwFPS1u6QBDOM2qB/KPDCCPjxq5o M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPK2wU6tJXG8/2dsb2JhbABEqWmBBYF0AQQSAScCAU4BgSYBBDWhSIEmAZ58hmqDFQSIEIwehUSMUw X-IronPort-AV: E=Sophos;i="4.69,512,1315180800"; d="scan'208";a="35964714" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 15 Nov 2011 00:50:30 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAF0oT6M026825 for <nea@ietf.org>; Tue, 15 Nov 2011 00:50:29 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); Mon, 14 Nov 2011 18:50:29 -0600 Received: from 10.70.231.57 ([10.70.231.57]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Tue, 15 Nov 2011 00:50:29 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Mon, 14 Nov 2011 19:50:38 -0500 From: Susan Thomson <sethomso@cisco.com> To: <nea@ietf.org> Message-ID: <CAE7218E.17ECB%sethomso@cisco.com> Thread-Topic: Comment re PT-TLS and SASL mechanism negotiation Thread-Index: AcyjMJdbz6YbGlBUk0inK5Tu++BMDg== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Nov 2011 00:50:29.0629 (UTC) FILETIME=[925DF2D0:01CCA330] Subject: [Nea] Comment re PT-TLS and SASL mechanism negotiation X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list <nea.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/nea>, <mailto:nea-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/nea> List-Post: <mailto:nea@ietf.org> List-Help: <mailto:nea-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/nea>, <mailto:nea-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Nov 2011 00:50:31 -0000 I have a comment on PT-TLS I-D and SASL mechanism negotiation. Re Sections 3.4.2.2. and 3.8.3: The text is unclear as to whether the PTC or the PTS starts the negotiation, leaving the possibility (if not the probability) that in a particular implementation neither side initiates the exchange (or both). In the common use case where the server has the policy requiring a client to authenticate, it must send a SASL mechanism message (unless the client is required to initiate the exchange, which is not what the spec currently says). It might be good to first list out the common use cases we need to support and the desired behavior, and then make sure that the draft reflects that. Right now, the draft supports all possible options, and it is not always clear what is expected to happen in any particular scenario. It also may be the case that the cost of supporting all these use cases outweighs the benefit - the more use cases we have, the more testing needs to be done, and the potential for interoperability issues rises. But before we reach this conclusion, it would be good to first clarify what use cases we think we need to support. Thanks Susan From shanna@juniper.net Tue Nov 15 07:36:43 2011 Return-Path: <shanna@juniper.net> 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 9DC3B11E8082 for <nea@ietfa.amsl.com>; Tue, 15 Nov 2011 07:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.165 X-Spam-Level: X-Spam-Status: No, score=-106.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3D+X0mapH4xj for <nea@ietfa.amsl.com>; Tue, 15 Nov 2011 07:36:43 -0800 (PST) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id D9F3911E8080 for <nea@ietf.org>; Tue, 15 Nov 2011 07:36:39 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTsKHAb244zJtbpsu7tONlqWa8IxkWZRj@postini.com; Tue, 15 Nov 2011 07:36:42 PST 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.3.213.0; Tue, 15 Nov 2011 07:33:48 -0800 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; Tue, 15 Nov 2011 10:33:47 -0500 From: Stephen Hanna <shanna@juniper.net> To: "nea@ietf.org" <nea@ietf.org> Date: Tue, 15 Nov 2011 10:33:45 -0500 Thread-Topic: Two More PT-TLS Issues Thread-Index: Acyjq/aYwk06roE8RI6ak1+uJ7PbPw== Message-ID: <AC6674AB7BC78549BB231821ABF7A9AEB80F841FA1@EMBX01-WF.jnpr.net> 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] Two More PT-TLS Issues X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list <nea.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/nea>, <mailto:nea-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/nea> List-Post: <mailto:nea@ietf.org> List-Help: <mailto:nea-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/nea>, <mailto:nea-request@ietf.org?subject=subscribe> X-List-Received-Date: Tue, 15 Nov 2011 15:36:43 -0000 In preparing the slides for this week's NEA meeting, the chairs and editors have uncovered two more PT-TLS issues that should be resolved. I'm sorry that these weren't raised during WGLC but it's good that they have been smoked out by the process and it's best to get them resolved ASAP so here they are. Let's discuss these on email and also during the NEA WG meeting.=20 First, PT-TLS supports a mode where the NEA Client is the TLS Server and the NEA Server is the TLS Client. In this mode, PT-TLS requires that the NEA Client use an X.509 certificate to authenticate itself during the TNC handshake (TLS server auth). No requirements are placed on how the NEA Server authenticates itself in this mode, although such authentication is clearly highly desirable. Since the NEA Server generally has an X.509 certificate for the more common situation where the NEA Client is the TNC Client, the simplest way to resolve this seems to be to require the NEA Server to use its X.509 certificate to authenticate itself during the TLS handshake, performing TLS mutual auth. This avoids the need for the NEA Client to support authenticating the NEA Server with SASL, simplifying implementation and testing. In the NEA meeting at IETF 81, Trevor Freeman asked why PT-TLS doesn't include a way to bind the inner SASL authentication to the TLS tunnel. Without that, an attacker could forward a SASL authentication through multiple PT-TLS tunnels. We agreed to figure out how to do channel binding and put that in PT-TLS. However, that isn't present in the current draft. It should be added. Thanks, Steve From sethomso@cisco.com Tue Nov 15 20:56:07 2011 Return-Path: <sethomso@cisco.com> 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 871781F0CB1 for <nea@ietfa.amsl.com>; Tue, 15 Nov 2011 20:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.99 X-Spam-Level: X-Spam-Status: No, score=-105.99 tagged_above=-999 required=5 tests=[AWL=-0.610, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D67HlGOciRLu for <nea@ietfa.amsl.com>; Tue, 15 Nov 2011 20:56:03 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 88DA61F0C9B for <nea@ietf.org>; Tue, 15 Nov 2011 20:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=1433; q=dns/txt; s=iport; t=1321419363; x=1322628963; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=p1pIEKk6g6JXDQCDU1ZPy/VCIl7fUG4NTqB4/8f3lWA=; b=iZjwn4QYwZUG8CUn4DtN8+40YG6TJOr+KPqPirPNOHnqSQoYzK60f6Bh VQfb5A6HtYAmPwRuzWjeMSGAdWD29JXMlP0p2fvi+P4KF/8RiqrpYGYsP 6jhMTp9DB44X1WTVdVMMFuJh4R63ydmEZyoGhPvt4I9yvBVAsbRcBa2Ib 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMBBw06tJV2d/2dsb2JhbABDqXKBBYF0AQQSAScCAU4BgSYBBDWhDYEmAZ5UhwKDFQSIFIwghUSMVg X-IronPort-AV: E=Sophos;i="4.69,519,1315180800"; d="scan'208";a="36399650" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 16 Nov 2011 04:56:03 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAG4u350002713 for <nea@ietf.org>; Wed, 16 Nov 2011 04:56:03 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 22:55:57 -0600 Received: from 10.70.231.225 ([10.70.231.225]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 16 Nov 2011 04:55:57 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Mon, 14 Nov 2011 19:27:31 -0500 From: Susan Thomson <sethomso@cisco.com> To: <nea@ietf.org> Message-ID: <CAE71C23.17EBA%sethomso@cisco.com> Thread-Topic: Comment on PT-TLS I-D and SASL Negotiation Thread-Index: AcyjLVyjvHlkndZ7U0KqsLczRmh5ag== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 16 Nov 2011 04:55:57.0964 (UTC) FILETIME=[078D44C0:01CCA41C] Subject: [Nea] Comment on PT-TLS I-D and SASL Negotiation X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list <nea.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/nea>, <mailto:nea-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/nea> List-Post: <mailto:nea@ietf.org> List-Help: <mailto:nea-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/nea>, <mailto:nea-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 16 Nov 2011 04:56:07 -0000 I have another comment on the PT-TLS I-D re SASL negotiation. Re Sections 3.4.2.2 and 3.8.3: The text leaves it open as to whether the PTC or the PTS initiates the SASL negotiation, leaving the possibility (if not the probability) that in certain implementations neither side will start the exchange. A common use case would be for the server to have the policy that requires client authentication, in which case the server must send a SASL mechanisms message (unless it can rely on the client kickstarting the negotiation, which is not what is specified). Of course, the other possibility (as the draft points out) is that both sides start the negotiation at the same time and there is the potential for a race condition. It might be good to first go through common scenarios and the desired behavior, and then make sure that the text in the spec reflects that desired behavior. Right now, it seems that the spec allows for all possible options of client trigger and server trigger, but in any particular scenario it is not clear from the text what is expected to happen. It might also be the case that the cost of supporting all these options may outweigh the benefit --- the more cases we have, the more testing needs to be done and the potential for interoperability issues rises. But before drawing this conclusion, lets first be clear what use cases we think we need to support. Thanks Susan From alexey.melnikov@isode.com Wed Nov 23 02:52:21 2011 Return-Path: <alexey.melnikov@isode.com> 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 A6B4021F8B88 for <nea@ietfa.amsl.com>; Wed, 23 Nov 2011 02:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.066 X-Spam-Level: X-Spam-Status: No, score=-102.066 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F7xQkDq96iA for <nea@ietfa.amsl.com>; Wed, 23 Nov 2011 02:52:19 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id ABBA221F8B90 for <nea@ietf.org>; Wed, 23 Nov 2011 02:52:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1322045537; d=isode.com; s=selector; i=@isode.com; bh=LKDQcfWKBx2YXtsVZx06u0B9fjI99I+a/DGvDByT334=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Et57xjq5X6WAxJivbWXJEvzkyC/koShZ5TdHy6EoNZqpBme323l4YbT7eRIxEUBtZ3zBlS lIsv2N0vuUeP/CZFVrPzCmr20U56jlYbOPkKCFRrhsZQYxtzp6hhivlgFkiXvtWi2OrHkE Hy/5Q3vzqjnmpZmVzDpu888S8nce5so=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TszQYQAFEA3C@rufus.isode.com>; Wed, 23 Nov 2011 10:52:17 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4ECCD076.7080003@isode.com> Date: Wed, 23 Nov 2011 10:52:38 +0000 From: Alexey Melnikov <alexey.melnikov@isode.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Paul Sangster <paul_sangster@symantec.com>, Nancy Cam-Winget <ncamwing@cisco.com>, Joseph Salowey <jsalowey@cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070305060404020208080507" X-Mailman-Approved-At: Wed, 23 Nov 2011 06:22:06 -0800 Cc: nea@ietf.org Subject: [Nea] Review of PT-TLS draft X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list <nea.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/nea>, <mailto:nea-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/nea> List-Post: <mailto:nea@ietf.org> List-Help: <mailto:nea-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/nea>, <mailto:nea-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 23 Nov 2011 10:52:21 -0000 This is a multi-part message in MIME format. --------------070305060404020208080507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I finished the review I've started during the Taipei IETF: I think text about using tls-unique channel binding with capable SASL mechanisms is missing. Not entirely sure what is the best place for it yet. 3.1.1. Issues with Server Initiated PT-TLS Sessions Another issue with this scenario involves X.509 certificates. I think RFC 5280 reference is missing here. 3.4.2. PT-TLS Message Exchange Phases The PT-TLS message exchange occurs in three distinct phases: o TLS Setup (including TLS Handshake protocol) o PT-TLS Negotiation o PT-TLS Data Transport The TLS Setup phase is responsible for the establishment of the TCP connection and the TLS protections for the PT-TLS messages. The TLS Setup phase normally starts with the establishment of a TCP connection between the Posture Transport Client and Posture Transport Server. The new connection triggers the TLS Handshake protocol to establish the cryptographic protections for the TLS session. The TLS Setup phase SHOULD NOT be repeated after the PT-TLS Data Transport phase has been reached unless a change of TLS cipher suite or keying material is required to properly protect the session. The last quoted sentence: does this mean TLS renegotiation extension or something else? I found this text to be unclear. This phase also enables the establishment of the tls-unique shared secret that can be used in a later phase to bind the posture sent with this TLS connection. 3.4.2.1. TLS Setup Phase During the TLS Setup phase of PT-TLS, the PT-TLS Initiator contacts the listening port of the PT-TLS Responder and performs a TLS handshake. The PT-TLS Responder MUST possess a trustworthy X.509 certificate used to authenticate to the TLS initiator and used to bootstrap the security protections of the TLS session. I think this is lacking some details about what kind of X.509 certificate is Ok and what is to be verified in it. I think you should use RFC 6125 here (at least for the case of NEA client talking to NEA server), if you can, as RFC 5280 allows for too much flexibility. The PT-TLS Initiator MAY also use an X.509 certificate to authenticate to the PT-TLS Responder providing for a bi-directional authentication of the PT-TLS session. In 3.4.2.2: first mention of SASL needs a reference. 3.4.3. TLS Requirements In order to ensure that strong security is always available for deployers and to improve interoperability, this section discusses some requirements on the underlying TLS transport used by PT-TLS. Implementations of PT-TLS MUST support use of TLS 1.1 [RFC4346] and SHOULD also include support for TLS 1.2 [RFC5246]. As per discussion diring the face-to-face meeting in Taipei: all major TLS 1.1 implementations seem to also support 1.2, so TLS 1.1 should be dropped and TLS 1.2 should be made a MUST. In 3.6: 9 (PT-TLS Error) PT-TLS Error message as described in section 3.9. This message type may be used during any PT-TLS phase. The corresponding IANA registration (Section 6.2) says: 0 11 PT-TLS Error RFC # Assigned to this I-D So one of these sections has an error. 10+ (Reserved) These values are reserved for future allocation following guidelines defined in the IANA Considerations section 6.1. Recipients of messages of type 13 or higher that do not Did you mean "10" here? support the PT-TLS Message Type Vendor ID and PT-TLS Message Type of a received PT-TLS message MUST respond with a Type Not Supported PT-TLS error code in a PT-TLS Error message. 3.8.2. SASL in PT-TLS Overview Mechanism negotiation is performed using the Request SASL Mechanisms and SASL Mechanisms TLVs. The PT-TLS Initiator sends a Request SASL Mechanisms TLV to request a preference-ordered list of SASL I think you should drop "preference-ordered" here: each SASL client should have its own policy regarding preference order and such policy is likely to be different from the server's policy. The client shouldn't be trusting server on this. mechanisms that the PT-TLS Responder is willing to use for this session. The PT-TLS Initiator selects one SASL mechanism from the list and sends a SASL Mechanism Selection TLV completing the negotiation. Subsequent challenges and responses are carried within the SASL Authentication Data TLV carrying the authentication data for the selected mechanism. The authentication outcome is communicated in a SASL Result TLV containing a status code. If additional authentications are required, the PT-TLS Responder could trigger the next authentication by sending another SASL Mechanisms TLV after sending the SASL Result TLV for the current authentication mechanism. 3.8.4. SASL Authentication Flow If an authentication is required by the PT-TLS Responder and not requested by the PT-TLS Initiator, the PT-TLS Responder (typically the NEA Server) SHOULD initiate the entity authentication exchange by sending a SASL Mechanisms TLV. If the PT-TLS Responder receives a NEA assessment message before the completion of any required entity authentication, the PT- TLS Responder MUST send an Authentication Required PT-TLS Error indicating to the PT-TLS Initiator that an authentication exchange is required prior to entering the PT-TLS Data Transport phase. The SASL Mechanisms TLV includes a preference-ordered list of the SASL mechanisms that the PT-TLS As above: drop "preference-ordered". Responder is willing to use and allows for the selection of one by the PT-TLS Initiator for use with this session. Your SASL profile doesn't seem to support "additional data with success" feature of SASL (which can save a round trip). I suggest you say so explicitly. Or alternatively you can update the message reporting outcome of a SASL authentication exchange to include this information. 3.8.6.3. SASL Security Layer The NEA PT-TLS protocol always runs under the protection of TLS. SASL security layers are not used. Add "and thus MUST be negotiated off during SASL authentication" to the end of this sentence. SASL security layers are negotiated during authentication using SASL mechanisms that support security layers. 3.8.6.4. Multiple Authentications Only one SASL mechanism authentication may be in progress at any one time. Once a SASL mechanism completes (successfully or unsuccessfully) a new authentication may be initiated. I think you need to talk somewhere that this profile of SASL doesn't support reauthentication (i.e. authentication as another user, after an earlier successful authentication) like LDAP does. Instead PT-TLS is supporting "multiple cumulative authentications" (I needed to invent a new term). 3.8.10. SASL Authentication Data This TLV carries an opaque (to PT-TLS) blob of octets being exchanged between the PT-TLS Initiator and the PT-TLS Responder. This TLV facilitates their communications without interpreting any of the bytes. The SASL Authentication Data TLV MUST NOT be sent until a SASL mechanism has been established for a session. The SASL Authentication Data TLV MUST NOT be sent after a SASL Result is sent with a Successful status. The last MUST NOT seem to prevent multiple authentications, which I don't think is the intent. 3.8.11. SASL Result This TLV is sent by the PT-TLS Responder at the conclusion of the SASL exchange to indicate the authentication result. This TLV may also be sent by the PT-TLS Initiator to indicate a client side failure. The PT-TLS Initiator MUST NOT send other Result-Code values besides Failure. Upon reception of a SASL Result TLV indicating an Abort, the recipient MUST terminate the current authentication conversation. The recipient may retry the authentication in the event of an authentication failure. Similarly, the NEA Server may request additional SASL authentication(s) be performed after the completion of a SASL mechanism by sending another SASL Mechanisms TLV. Can any such subsequent list include authentication mechanisms already successfully used earlier in the same session? 3.8.11. SASL Result 1 (Failure) SASL authentication failed. This might be caused by the entity providing an invalid user identity and/or credential pair. Note that this is not a mechanism failure to process the authentication. What is the meaning of the last sentence? If you meant to say that that is different from 3: 3 (Mechanism Failure) SASL mechanism failure during the processing of the entity's authentication (not related to the user's input). then you should say so above (maybe quote "Mechanism Failure"?) s/user's input/authentication mechanism's input (Not all of it is "user's input") Additionally, it is not very clear whether this covers any errors other than "unsupported SASL mechanism name". And finally, can you just use "error message" (Section 3.9) for reporting SASL authentication errors instead? 3.9. Error Message 4 (Failed Authentication) The authentication of the identity of the client failed. This could occur if the SASL mechanism was unable to authenticate the claimed identity of the PT-TLS Initiator. This error message does not indicate a fatal error has occurred, so the authentication is allowed to be re- started. I am confused, I thought this condition should have resulted in "SASL result" with Fail status. 4.2.5. NEA Asokan Attacks Because lying endpoint attacks are much easier than Asokan attacks and the only known effective countermeasure against lying endpoint attacks is the use of an External Measurement Agent (EMA), countermeasures against an Asokan attack are not necessary unless an EMA is in use. However, PT-TLS implementers may not know whether an EMA will be used with their implementation. Therefore, PT-TLS implementers SHOULD support the Asokan attack countermeasures by providing the value of the tls-unique channel binding to higher layers in the NEA reference model: Posture Broker Clients, Posture Broker Servers, Posture Collectors, and Posture Validators. Mention SASL here as well (e.g. use of tls-unique with SASL mechanisms that support channel bindings)? 6.1. Designated Expert Guidelines Instead, designated experts should focus on the following requirements. All values in these IANA registries MUST be documented in a specification that is permanently and publicly available. IETF standard values MUST also be useful, not For clarity I would replace "IETF standard values" with "Values defined in Standards Track RFCs". harmful to the Internet, and defined in a manner that is clear and likely to ensure interoperability. --------------070305060404020208080507 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#FFFFFF" text="#000000"> <span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "> <pre style="word-wrap: break-word; white-space: pre-wrap; ">Hi, I finished the review I've started during the Taipei IETF:</pre> </span><br> I think text about using tls-unique channel binding with capable SASL mechanisms is missing. Not entirely sure what is the best place for it yet.<br> <br> <br> 3.1.1. Issues with Server Initiated PT-TLS Sessions<br> <br>    Another issue with this scenario involves X.509 certificates.<br> <br> I think RFC 5280 reference is missing here.<br> <br> <br> <br> 3.4.2. PT-TLS Message Exchange Phases<br> <br>    The PT-TLS message exchange occurs in three distinct phases:<br>    o  TLS Setup (including TLS Handshake protocol)<br> <br>    o  PT-TLS Negotiation<br> <br>    o  PT-TLS Data Transport<br> <br>    The TLS Setup phase is responsible for the establishment of the TCP<br>    connection and the TLS protections for the PT-TLS messages.  The TLS<br>    Setup phase normally starts with the establishment of a TCP<br>    connection between the Posture Transport Client and Posture Transport<br>    Server.  The new connection triggers the TLS Handshake protocol to<br>    establish the cryptographic protections for the TLS session.  The TLS<br>    Setup phase SHOULD NOT be repeated after the PT-TLS Data Transport<br>    phase has been reached unless a change of TLS cipher suite or keying<br>    material is required to properly protect the session.<br> <br> The last quoted sentence: does this mean TLS renegotiation extension or something else?<br> I found this text to be unclear.<br> <br>    This phase<br>    also enables the establishment of the tls-unique shared secret that<br>    can be used in a later phase to bind the posture sent with this TLS<br>    connection.<br> <br> <br> <br> 3.4.2.1. TLS Setup Phase<br> <br>    During the TLS Setup phase of PT-TLS, the PT-TLS Initiator contacts<br>    the listening port of the PT-TLS Responder and performs a TLS<br>    handshake.  The PT-TLS Responder MUST possess a trustworthy X.509<br>    certificate used to authenticate to the TLS initiator and used to<br>    bootstrap the security protections of the TLS session.<br> <br> I think this is lacking some details about what kind of X.509<br> certificate is Ok and what is to be verified in it. I think you should<br> use RFC 6125 here (at least for the case of NEA client talking to NEA server),<br> if you can, as RFC 5280 allows for too much flexibility.<br> <br>    The PT-TLS<br>    Initiator MAY also use an X.509 certificate to authenticate to the<br>    PT-TLS Responder providing for a bi-directional authentication of the<br>    PT-TLS session.<br> <br> <br> In 3.4.2.2: first mention of SASL needs a reference.<br> <br> <br> <br> 3.4.3. TLS Requirements<br> <br>    In order to ensure that strong security is always available for<br>    deployers and to improve interoperability, this section discusses<br>    some requirements on the underlying TLS transport used by PT-TLS.<br>    Implementations of PT-TLS MUST support use of TLS 1.1 [RFC4346] and<br>    SHOULD also include support for TLS 1.2 [RFC5246].<br> <br> As per discussion diring the face-to-face meeting in Taipei:<br> all major TLS 1.1 implementations seem to also support 1.2,<br> so TLS 1.1 should be dropped and TLS 1.2 should be made a MUST.<br> <br> In 3.6:<br> <br>      9 (PT-TLS Error)            PT-TLS Error message as described in<br>                                  section 3.9.  This message type may be<br>                                  used during any PT-TLS phase.<br> <br> The corresponding IANA registration (Section 6.2) says:<br>     0     11     PT-TLS Error             RFC # Assigned to this I-D<br> <br> So one of these sections has an error.<br> <br> <br>      10+ (Reserved)              These values are reserved for future<br>                                  allocation following guidelines<br>                                  defined in the IANA Considerations<br>                                  section 6.1.  Recipients of messages<br>                                  of type 13 or higher that do not<br> <br> Did you mean "10" here?<br> <br>                                  support the PT-TLS Message Type Vendor<br>                                  ID and PT-TLS Message Type of a<br>                                  received PT-TLS message MUST respond<br>                                  with a Type Not Supported PT-TLS error<br>                                  code in a PT-TLS Error message.<br> <br> <br> 3.8.2. SASL in PT-TLS Overview<br> <br>    Mechanism negotiation is performed using the Request SASL Mechanisms<br>    and SASL Mechanisms TLVs.  The PT-TLS Initiator sends a Request SASL<br>    Mechanisms TLV to request a preference-ordered list of SASL<br> <br> I think you should drop "preference-ordered" here: each SASL client should have<br> its own policy regarding preference order and such policy is likely to be different from<br> the server's policy. The client shouldn't be trusting server on this.<br> <br>    mechanisms that the PT-TLS Responder is willing to use for this<br>    session.  The PT-TLS Initiator selects one SASL mechanism from the<br>    list and sends a SASL Mechanism Selection TLV completing the<br>    negotiation.  Subsequent challenges and responses are carried within<br>    the SASL Authentication Data TLV carrying the authentication data for<br>    the selected mechanism.  The authentication outcome is communicated<br>    in a SASL Result TLV containing a status code.  If additional<br>    authentications are required, the PT-TLS Responder could trigger the<br>    next authentication by sending another SASL Mechanisms TLV after<br>    sending the SASL Result TLV for the current authentication mechanism.<br> <br> <br> 3.8.4. SASL Authentication Flow<br> <br>    If an authentication is required by the PT-TLS Responder and<br>    not requested by the PT-TLS Initiator, the PT-TLS Responder<br>    (typically the NEA Server) SHOULD initiate the entity<br>    authentication exchange by sending a SASL Mechanisms TLV.  If<br>    the PT-TLS Responder receives a NEA assessment message before<br>    the completion of any required entity authentication, the PT-<br>    TLS Responder MUST send an Authentication Required PT-TLS Error<br>    indicating to the PT-TLS Initiator that an authentication<br>    exchange is required prior to entering the PT-TLS Data<br>    Transport phase.  The SASL Mechanisms TLV includes a<br>    preference-ordered list of the SASL mechanisms that the PT-TLS<br> <br> As above: drop "preference-ordered".<br> <br>    Responder is willing to use and allows for the selection of one<br>    by the PT-TLS Initiator for use with this session.<br> <br> <br> <br> Your SASL profile doesn't seem to support  "additional data with success"<br> feature of SASL (which can save a round trip). I suggest you say so explicitly.<br> Or alternatively you can update the message reporting outcome of a SASL<br> authentication exchange to include this information.<br> <br> <br> <br> 3.8.6.3. SASL Security Layer<br> <br>    The NEA PT-TLS protocol always runs under the protection of TLS.<br>    SASL security layers are not used.<br> <br> Add "and thus MUST be negotiated off during SASL authentication" to<br> the end of this sentence. SASL security layers are negotiated during<br> authentication using SASL mechanisms that support security layers.<br> <br> <br> 3.8.6.4. Multiple Authentications<br> <br>    Only one SASL mechanism authentication may be in progress at any one<br>    time.  Once a SASL mechanism completes (successfully or<br>    unsuccessfully) a new authentication may be initiated.<br> <br> I think you need to talk somewhere that this profile of SASL<br> doesn't support reauthentication (i.e. authentication as another user,<br> after an earlier successful authentication) like LDAP does.<br> Instead PT-TLS is supporting "multiple cumulative authentications"<br> (I needed to invent a new term).<br> <br> 3.8.10. SASL Authentication Data<br> <br>    This TLV carries an opaque (to PT-TLS) blob of octets being exchanged<br>    between the PT-TLS Initiator and the PT-TLS Responder.  This TLV<br>    facilitates their communications without interpreting any of the<br>    bytes.  The SASL Authentication Data TLV MUST NOT be sent until a<br>    SASL mechanism has been established for a session.  The SASL<br>    Authentication Data TLV MUST NOT be sent after a SASL Result is sent<br>    with a Successful status.<br> <br> The last MUST NOT seem to prevent multiple authentications, which<br> I don't think is the intent.<br> <br> 3.8.11. SASL Result<br> <br>    This TLV is sent by the PT-TLS Responder at the conclusion of the<br>    SASL exchange to indicate the authentication result.  This TLV may<br>    also be sent by the PT-TLS Initiator to indicate a client side<br>    failure.  The PT-TLS Initiator MUST NOT send other Result-Code values<br>    besides Failure.  Upon reception of a SASL Result TLV indicating an<br>    Abort, the recipient MUST terminate the current authentication<br>    conversation.  The recipient may retry the authentication in the<br>    event of an authentication failure.  Similarly, the NEA Server may<br>    request additional SASL authentication(s) be performed after the<br>    completion of a SASL mechanism by sending another SASL Mechanisms<br>    TLV.<br> <br> Can any such subsequent list include authentication mechanisms already<br> successfully used earlier in the same session?<br> <br> <br> 3.8.11. SASL Result<br> <br>        1 (Failure)               SASL authentication failed.  This<br>                                  might be caused by the entity<br>                                  providing an invalid user identity<br>                                  and/or credential pair.  Note that<br>                                  this is not a mechanism failure to<br>                                  process the authentication.<br> <br> What is the meaning of the last sentence?<br> <br> If you meant to say that that is different from 3:<br> <br>        3 (Mechanism Failure)     SASL mechanism failure during the<br>                                  processing of the entity's<br>                                  authentication (not related to the<br>                                  user's input).<br> <br> then you should say so above (maybe quote "Mechanism Failure"?)<br> <br> <br> s/user's input/authentication mechanism's input<br> (Not all of it is "user's input")<br> <br> Additionally, it is not very clear whether this covers any errors other<br> than "unsupported SASL mechanism name".<br> <br> And finally, can you just use "error message" (Section 3.9) for reporting<br> SASL authentication errors instead?<br> <br> <br> <br> 3.9. Error Message<br> <br>        4 (Failed Authentication) The authentication of the identity of<br>                                  the client failed.  This could occur<br>                                  if the SASL mechanism was unable to<br>                                  authenticate the claimed identity of<br>                                  the PT-TLS Initiator.  This error<br>                                  message does not indicate a fatal<br>                                  error has occurred, so the<br>                                  authentication is allowed to be re-<br>                                  started.<br> <br> I am confused, I thought this condition should have resulted in "SASL result"<br> with Fail status.<br> <br> <br> 4.2.5. NEA Asokan Attacks<br> <br>    Because lying endpoint attacks are much easier than Asokan attacks<br>    and the only known effective countermeasure against lying endpoint<br>    attacks is the use of an External Measurement Agent (EMA),<br>    countermeasures against an Asokan attack are not necessary unless an<br>    EMA is in use. However, PT-TLS implementers may not know whether an<br>    EMA will be used with their implementation.  Therefore, PT-TLS<br>    implementers SHOULD support the Asokan attack countermeasures by<br>    providing the value of the tls-unique channel binding to higher<br>    layers in the NEA reference model: Posture Broker Clients, Posture<br>    Broker Servers, Posture Collectors, and Posture Validators.<br> <br> Mention SASL here as well (e.g. use of tls-unique with SASL mechanisms<br> that support channel bindings)?<br> <br> 6.1. Designated Expert Guidelines<br> <br>    Instead, designated experts should focus on the following<br>    requirements.  All values in these IANA registries MUST be<br>    documented in a specification that is permanently and publicly<br>    available. IETF standard values MUST also be useful, not<br> <br> For clarity I would replace "IETF standard values" with "Values<br> defined in Standards Track RFCs".<br> <br>    harmful to the Internet, and defined in a manner that is clear<br>    and likely to ensure interoperability.<br> <br> </body> </html> --------------070305060404020208080507-- From sethomso@cisco.com Wed Nov 23 17:21:43 2011 Return-Path: <sethomso@cisco.com> 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 8ED7421F86A1 for <nea@ietfa.amsl.com>; Wed, 23 Nov 2011 17:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.814 X-Spam-Level: X-Spam-Status: No, score=-105.814 tagged_above=-999 required=5 tests=[AWL=-0.611, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se9Z8U3muv6G for <nea@ietfa.amsl.com>; Wed, 23 Nov 2011 17:21:42 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id F30EB21F8678 for <nea@ietf.org>; Wed, 23 Nov 2011 17:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=14225; q=dns/txt; s=iport; t=1322097702; x=1323307302; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=yxiiAIdqfKNNO5FBZRZ2n+R3vBWBY+744+0Yz1kgJe8=; b=Jdk6UfaNtUOveVrDLf7BUeeO4mtOnU4QWrT+RcOiTuMS5tNPtEqffhU/ oHiafcFQfjc0AshAxX72NfosXudC29VFkinOtuwqgsbNcAghPP62HC1oW mSjOOMReycml9mSPBqkYJrsu8iZGWEYlnG4Yq7aWZ1DYW6JxqdWrfrH7l I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALebzU6tJXG//2dsb2JhbABEqW+BBoEFgXQBBBIBKQEqBx0BHIEKAQQKCQkZh2uUc4EmAZ4nimIEh28xjCiSKA X-IronPort-AV: E=Sophos;i="4.69,562,1315180800"; d="scan'208";a="38622301" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 24 Nov 2011 01:21:41 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAO1LfKV000411 for <nea@ietf.org>; Thu, 24 Nov 2011 01:21:41 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Nov 2011 19:21:41 -0600 Received: from 10.116.64.98 ([10.116.64.98]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 24 Nov 2011 01:21:41 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Wed, 23 Nov 2011 20:22:05 -0500 From: Susan Thomson <sethomso@cisco.com> To: <nea@ietf.org> Message-ID: <CAF3066D.184B6%sethomso@cisco.com> Thread-Topic: Draft minutes from IETF82 Thread-Index: AcyqR3nQWKQVMMrIfkCbQ/CfUehOnQ== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 24 Nov 2011 01:21:41.0068 (UTC) FILETIME=[6B8CA0C0:01CCAA47] Subject: [Nea] Draft minutes from IETF82 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list <nea.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/nea>, <mailto:nea-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/nea> List-Post: <mailto:nea@ietf.org> List-Help: <mailto:nea-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/nea>, <mailto:nea-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 24 Nov 2011 01:21:43 -0000 Draft minutes below. Please send corrections to me by Friday, Dec 2. Thanks Susan -------------------------- These notes do not attempt to duplicate the content of the slides. Instead, they summarize the material presented, and focus on comments and discussion. Notes taken by Chris Inacio. Agenda =3D=3D=3D=3D=3D=3D Date: Thursday, Nov 17, 2011 Time: 0900-1130=20 WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org 0900 Administrivia Jabber & Minute scribes Agenda bashing 0905 WG Status 0910 NEA Reference Model 0915 Discuss and Resolve Open WGLC PT-TLS Comments draft-ietf-nea-pt-tls-01.txt 1000 Discuss and Resolve PT_EAP Issues draft-ietf-nea-pt-eap-00.txt 1100 Discuss next steps for NEA Asokan I-D 1115 Discuss Next Steps 1130 Adjourn WG Status =3D=3D=3D=3D=3D=3D=3D=3D=3D Susan Thomson reviewed WG status. Since the last IETF, PT-TLS I-D has gone through WGLC. Several issues have been raised which will be discussed in the meeting today. PT-EAP was published as a WG document. Some comments have been received, but more are needed. Discuss and Resolve WGLC PT-TLS Comments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Joe Salowey went through the list of issues that had been brought up on the mailing list in response to WGLC. Issues include: 1)TLS Keepalive 2)Version Negotiation 3)SASL Negotiation 4)PT Client as TLS Server 5)Channel Bindings 1) TLS Keepalive To address the issue of how to keep the TLS session up, the proposal is to use the TLS heartbeat mechanism described in draft-ietf-tls- dtls-heartbeat. This draft is going through the IESG now, and should be an RFC prior to the PT-TLS being published. The keepalive mechanism would be optional to implement. Stephen Farrell raised the question of whether it should be optional to implement for both sides. Steve Hanna said it could be mandatory to implement at the NEA server. Joe asked for clarification of the use case. Steve said that the use case would be that the TLS session needs to be kept up to allow the NEA server to revalidate the client after some period, which may leave a long time during which the TLS session is not carrying traffic. Nancy Cam-Winget asked for clarification on the need to implement the TLS server on the NEA client. Steve says that he is pretty sure that the draft does not require that NEA clients need to implement the TLS Server. Nancy says that this should be made clear in the draft. Joe summarized by saying that the draft currently allows the NEA server to be a TLS server or a TLS Client. If we made keepalives mandatory to implement on the NEA server, this would enable the NEA server to revalidate the client without having to start a new TLS session (assuming the client supported it). Joe continued that the keepalive capability is negotiated at the TLS layer, so if the client did not support this, there would be a degradation of service, not a hard failure. Joe said that the editors would get together to think through the ramifications of making this optional versus mandatory and make a proposal to the list. 2) Version Negotiation Regarding version negotiation, the draft says the following: =B3Subsequent assessments on the same session MUST use the negotiated version number and therefore SHOULD NOT send additional version negotiation messages.=B2 The proposal is to change the SHOULD NOT to a MUST NOT. Steve said that there is no point in allowing further version negotiation given that the protocol forbids a different version to be used during a session. Joe says we would need to check that the draft handles the error case. Alexey asked whether this discussion was referring to TLS version negotiation. Joe clarified it was PT-TLS. There were no objections to making this change. 3)SASL Initiation Currently, the draft allows for both the SASL client and server to initiate the SASL exchange. This leads to some additional complexity in the protocol, and the draft is not clear on the behavior in all cases. One proposal would be to have the TLS server always initiate the SASL exchange since it has the policy determining whether the client needs to be authenticated. The client would not have a way to initiate the exchange. Alexey asked a clarifying question about whether the server initiates the exchange by sending a list of SASL mechanisms (answer is yes), in which case he thought this proposal made sense. Joe said the only need he can think of for the client to initiate the SASL exchange is in the case where the client did not completely trust the server authentication done at the TLS layer, e.g. the trust root was questionable, and wanted to fall back to inner authentication such as a SASL GSS-API mechanism which allows for mutual authentication and channel binding to be verified. Joe thinks this is an edge case, and that we probably do not need to support this. Joe asked whether there were any objections to just supporting a server-initiated SASL exchange. There were no objections to this at the meeting, and further resolution would be taken to the list. Alexey asked whether, if authentication using one mechanism failed, the client can try another one that has been advertized. Joe says he is not sure how the draft deals with this at the moment, but in the case where the server-initiated exchange only is supported, the server could resend the mechanisms again. Alexey said that he did not think it was necessary for the server to send the mechanisms again, as the client already has the list and can pick another one. But either way, the draft needs to explain how this is supported. Alexey says that supporting this functionality is common SASL usage. Other protocols allow it. Steve says that the draft does permit this now, where the PT-TLS responder can send another SASL Mechanisms TLV if additional authentication is needed. It does not explicitly call out the error case, but does not preclude it. 4)PT-Client as TLS Server The current draft allows the NEA Client to be a TLS Server so that the NEA Server can initiate posture validation with the client. The question is how to support server authentication in this case. The proposal is to require mutual authentication at the TLS layer, and not use SASL in this case, thus simplifying the protocol. Steve says that while he is in favor of this approach, he does not think we should prohibit SASL authentication. Joe says that currently the SASL authentication is tied to the role the NEA client and server are playing in the PT-TLS exchange. It seems unlikely that the client would use SASL to authenticate the server in this case, but its possible the server might want to do additional authentication of the NEA client. Hao Zhou says he believes the current draft says that the SASL request can be sent only by the PT-TLS responder. If we want to allow this case, then we would need to make a change. Joe agreed, and said that there are probably other areas that need to be clarified. Steve said that assuming we decide to support this, we can rewrite the text in terms of PT-TLS client and server (versus PT-TLS initiator and responder) to make the expected behavior clearer. To be continued on the list. 5)Channel Binding It is desirable to be able to bind authentication to TLS channel, when possible. For example, SASL GS2 mechanism provides for this. The proposal is to describe this in the document. What Joe is not sure about is whether there are other mechanisms that support this capability. Alexey indicated that SCRAM does. Joe asked whether they use the same data structure used in GSS-API for tls-unique. Alexey thinks so. He supports adding tls-unique channel bindings to the draft.=20 Steve says there are a couple of sentences on channel binding in Section 3.8.1 of the current draft, but more text needs to be added. Susan asked whether there were other issues that the WG wanted to bring up. Alexey brought up the following additional issues: TLS Version: TLS1.1 is currently mandated. Concern that TLS 1.1 not widely deployed, and suggested that TLS 1.2 should be mandated instead. TLS 1.1. and 1.2 is available in libraries such as Opera, MS, OpenSSL (trunk version). The proposal is to mandate TLS 1.2. X.509 Certs: The draft does not specify what is expected in certificates, such as make use of RFC6125. RFC5280 is not sufficient as it has too many options. This works for the situation where client initiates TLS session, but there is an issue in the reverse direction, where the server may not know the client=B9s name. Stephen Farrell agreed that the reverse direction is tricky, and asked whether there are privacy concerns that need to be addressed as well. Joe indicated that we should note this as an issue in Privacy Considerations. PT-EAP: Nancy went through the comments received on PT-EAP I-D. Looking for more comments from the WG. The draft currently uses several acronyms to refer to the EAP method, the outer tunnel, or some combination. The proposal is to focus the document on the EAP method which carries the NEA data only, and refer to it as PT- EAP. =20 Steve agreed saying we have enough acronyms already. The above requires changes throughout the document. Specifically, Nancy has proposed changes to simplify the abstract and introduction given the above. She has also incorporated a comment from Steve Hanna that allows the EAP method to run in an EAP tunnel method =B3or equivalent protection=B2 Stephen Farrell raised the issue of what =B3equivalent protection=B2 really means. Steve said that the tunnel properties are defined in RFC5209 and in security considerations. Stephen responded that this leaves implementers hanging, but this is acceptable as long as it is clear that a TLS tunnel method must be implemented. Hao said there are inconsistencies in the proposed text around requiring an outer TLS tunnel method, or =B3equivalent protection=B2. Joe raised the question of whether this text is implying non-TLS-based EAP tunnel methods. Steve clarified that he wants to make sure that we support the proxy case from one RADIUS server to another. Joe says he still has a lot of problems with that use case and believes there are security issues that need to be addressed in the document. Steve said that there is an agreement to use EAP tunnel method, but there is still disagreement on the proxy case. This needs to be addressed directly on the mailing list, and if the consensus is that it is unsafe to do so, the spec should prohibit it, and if it is safe to do so under certain conditions, the spec must state what those conditions are. Nancy then proposed to remove references to the TNC document within the main text, and add text to the acknowledgements section. Steve disagreed saying he thought it was important to let readers know that the IETF spec and the TNC specs are equivalent. The TNC specs will be updated to be the same as the IETF document. Stephen Farrell says that this should be taken offline to come up with text that makes everyone happy. Nancy also proposed that a new EAP type should be assigned to PT-EAP. Stephen F. asked about the process for allocating the new EAP type. Joe suggested that at the time of WGLC, EMU WG be notified. Stephen F. suggested removing the Appendix, which describes how the protocol meets the requirements. It is no longer needed. Hao asked why a version registry is needed in IANA considerations. If changes are made, a new RFC will be issued. Susan proposed not including support in PT-EAP for fragmentation, at least where EAP tunnel method transports are mandated. EAP tunnel methods will support sending packets of up to approx 64K as is, and if more posture information needs to be transferred, then there is an alternate mechanism to use which is PT-TLS. Steve says he is fine with this as it encourages people to do the right thing, and simplifies interoperability and testing. NEA Asokan Analysis I-D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This I-D is referenced by both PT-TLS and PT-EAP I-Ds as informational. The question is whether the WG wants to make this a WG document with the intent to publish as an Informational RFC. A consensus check was taken and no objections raised. Stephen Farrell asked whether this would be useful to a more general audience, otherwise the text could be included in one draft and the other draft could reference it. Steve said that the draft is currently focused specifically on the Asokan attack in the NEA context, but it may be useful to raise awareness of the Asokan attack in general. Stephen F. suggested the draft be generalized so that it is not only specific to NEA, assuming this was not too much additional work. Joe said that it would be worthwhile investigating to see what it would take as he thinks the document would be useful to a wider audience. Next Steps: Susan summarized the next steps. The PT-TLS spec will be revised after all the issues have been addressed and another WGLC done. More comments are needed on PT-EAP. Hao and Kathleen volunteered to review the document. Joe and Steve will scope the amount of work needed to generalize the NEA Asokan I-D. Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Susan went through a new set of proposed milestones, as listed on the slides.=20 Stephen said that it looks like the NEA WG could be completed prior to the IETF in Paris, and that we should not assume that we need a meeting in Paris. It seems that with more mailing list participation, this is doable. The forcing function is that if there is insufficient mailing list discussion, then there may not be a meeting as agenda slots are tight. Meeting adjourned.