From Paul_Sangster@symantec.com Mon Dec 12 16:52:15 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8DA21F851F for ; Mon, 12 Dec 2011 16:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCxk3qJ9oAYD for ; Mon, 12 Dec 2011 16:52:15 -0800 (PST) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) by ietfa.amsl.com (Postfix) with ESMTP id 24F9D21F851A for ; Mon, 12 Dec 2011 16:52:14 -0800 (PST) X-AuditID: d80ac3f2-b7fb26d00000530c-57-4ee6a1baf906 Received: from tus1smtintpin01.ges.symantec.com (TUS1SMTINTPIN01.ges.symantec.com [192.168.215.101]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id BC.55.21260.AB1A6EE4; Mon, 12 Dec 2011 17:52:10 -0700 (MST) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1RaGbK-0006iP-8M; Mon, 12 Dec 2011 16:52:10 -0800 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Mon, 12 Dec 2011 16:52:10 -0800 From: Paul Sangster To: Carolin Latze , "nea@ietf.org" Date: Mon, 12 Dec 2011 16:52:08 -0800 Thread-Topic: [Nea] Extending WG Last Call on PT-TLS I-D Thread-Index: AcyazMSELT0H7lPPQEebreIzB/yDVAeZJaWA Message-ID: <6E79D623502C70419A9EAB18E4D274252A9E86480A@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4EB3A450.8090301@angry-red-pla.net> In-Reply-To: <4EB3A450.8090301@angry-red-pla.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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42I5sOJ6qu6uhc/8DO71i1q8fLmY3eLz2woH Jo+XT46yeSxZ8pMpgCmKyyYlNSezLLVI3y6BK2PPp2lsBS0SFZsfLWJqYOwW7mLk5JAQMJFY MvEDM4QtJnHh3nq2LkYuDiGBj4wS01p/MUE4rxklns+4zA5SJSSwilHi6OZkEJtNwEBi55FT YHERAS+J5Us2gtksAqoSV/Y+ApsqLGAucfbOOaBBHEA1FhI3X/hAlBtJNK5uYAOxeQWiJBZf 2MsMsWsGo8Tybf9ZQOo5BQwlNh3PAKlhBDru+6k1TCA2s4C4xK0n85kgjhaQWLLnPNQDohIv H/9jhagXlbjTvp4Rol5HYsHuT2wQtrbEsoWvmSH2CkqcnPmEZQKj2CwkY2chaZmFpGUWkpYF jCyrGGVKSosNi3NL8ktLClIrDIz0iitzE4FxlKyXnJ+7iREYSze4Dn/awXhjqeIhRgEORiUe 3sA5z/yEWBPLgCoPMUpwMCuJ8Ma6AYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzSlVe8xMSSE8s Sc1OTS1ILYLJMnFwSjUwRnqfMTqretn7tKSX7pU8nXOOx+6di/tXnxogJRv/pO7u1vyA6JB5 a/2czU4bLFqps0Z34Y3/F57o9DSLhTBuuHA3SeHxU5aP0YFl2ZMZRFiquE8dv1+5kvmt3psy jUsBvssbvxw5tjFLvzXnaVjPe6OzO3LC732Lifvyt2ji5L8ztuyc2zm3QImlOCPRUIu5qDgR ALoK4KGhAgAA 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: Tue, 13 Dec 2011 00:52:16 -0000 Thanks for the comments, some comments/proposed solutions are below... > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of=20 > Carolin Latze > Sent: Friday, November 04, 2011 1:38 AM > To: nea@ietf.org > Subject: Re: [Nea] Extending WG Last Call on PT-TLS I-D >=20 > I did not read the complete draft again, but checked it mainly against=20 > my last comments: >=20 > - section 3.1.1: would it make sense to specify how to keep the TLS=20 > session alive? I think it might be helpful to ensure interoperability [PS:] Good idea, we propose adding a SHOULD reference to the soon-to-be-RFC= TLS heartbeat (currently draft-ietf-tls-dtls-heartbeat) to address this it= em. >=20 > - section 3.6, type 8: maybe add "[RFC5793]" so that readers know=20 > where to find the PB-TNC spec [PS:] We already included this reference at the first use of PB-TNC higher = in the document. >=20 > - section 3.9: error code 6 exists twice (SASL Mech Error & Auth Need) [PS:] Thanks, we'll fix that. >=20 > regards > Carolin >=20 > 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 > > >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From Paul_Sangster@symantec.com Mon Dec 12 16:54:54 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 8B7D811E8089 for ; Mon, 12 Dec 2011 16:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaVBd5dQRGQ2 for ; Mon, 12 Dec 2011 16:54:54 -0800 (PST) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) by ietfa.amsl.com (Postfix) with ESMTP id DEF8011E8082 for ; Mon, 12 Dec 2011 16:54:53 -0800 (PST) X-AuditID: d80ac3f3-b7fea6d000006a28-fa-4ee6a25d495e Received: from ecl1mtahubpin01.ges.symantec.com (ECL1MTAHUBPIN01.ges.symantec.com [10.48.69.201]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id 6A.73.27176.D52A6EE4; Mon, 12 Dec 2011 17:54:53 -0700 (MST) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by ecl1mtahubpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1RaGdw-0006q8-MQ; Mon, 12 Dec 2011 19:54:53 -0500 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Mon, 12 Dec 2011 16:54:52 -0800 From: Paul Sangster To: Susan Thomson , "nea@ietf.org" Date: Mon, 12 Dec 2011 16:54:50 -0800 Thread-Topic: Comment re PT-TLS and SASL mechanism negotiation Thread-Index: AcyjMJdbz6YbGlBUk0inK5Tu++BMDgWASlqQ Message-ID: <6E79D623502C70419A9EAB18E4D274252A9E864813@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42LhMnA9qRu76JmfwcpDahaf31ZYPF0zhcmB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgynjScYmlYJZExbtnC1gaGA8JdzFyckgImEh0 N65jg7DFJC7cWw9kc3EICbxjlPj26AkLhPOaUeLOssOsIFVCAqsYJfZtKAOx2QQMJHYeOcXe xcjBISLgKvFxYjVImEVAVeLRkk9g5cICthKT3jSygNgiAnYSl+5sZIQoN5LoPpYIEuYViJK4 d2IGC0hYSEBfYsU9bpAwJ9Dwu7PeM4HYjECnfT+1BsxmFhCXuPVkPhPEyQISS/acZ4awRSVe Pv7HClEvKnGnfT0jRL2OxILdn9ggbG2JZQtfM0OsFZQ4OfMJywRGsVlIxs5C0jILScssJC0L GFlWMcqUlBYbFueW5JeWFKRWGBjrFVfmJgJjKFkvOT93EyMwjm5wHf68g3HhD/1DjAIcjEo8 vFXzn/kJsSaWAVUeYpTgYFYS4Y11AwrxpiRWVqUW5ccXleakFh9ilOZgURLnPVtxzU9IID2x JDU7NbUgtQgmy8TBKdXAOKH+470DyTsZ9/+84sLrF+Lx0ypn4+/lURq6r34l3lHsFVnx/t7t awcSV116JBbaMPk7yyyTXV5rmlurzU6b/X78xFZsQzyL02vlUy27fAMquO2PLtLxPJK+XK+j 8vi5rG9yr1++NwgJXWN4IULvwd/t3D9LuvgeG0045eL8JSou5jyzwNrDOUosxRmJhlrMRcWJ APA+/SmfAgAA Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 00:54:54 -0000 Susan, Comments and proposed remedies are discussed below... > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of=20 > Susan Thomson > Sent: Monday, November 14, 2011 4:51 PM > To: nea@ietf.org > Subject: [Nea] Comment re PT-TLS and SASL mechanism negotiation >=20 > I have a comment on PT-TLS I-D and SASL mechanism negotiation. >=20 > Re Sections 3.4.2.2. and 3.8.3: >=20 > The text is unclear as to whether the PTC or the PTS starts the=20 > negotiation, leaving the possibility (if not the probability) that in=20 > a particular implementation neither side initiates the exchange (or=20 > both). [PS:] In section 3.4.2.2, the first sentence says: "Once a TLS session has been established between Posture Transport Client a= nd Posture Transport Server, the PT-TLS Initiator sends a Version Request M= essage indicating it is supported PT-TLS protocol version range."=20 Because either side may have initiated the TLS Setup Phase (e.g. NEA Client= or Server could have triggered the TLS session), we use the term "PT-TLS I= nitiator". This means who ever initiated the PT-TLS session goes first fo= r version negotiation (not a race condition). However for section 3.8.3 (SASL authentication), the -01 draft allows eithe= r party to initiate without a deadlock. However this does introduce comple= xity so unless a use case for either side initiating the client (currently = "entity") authentication then we will modify section 3.8 to just have the P= TS initiate the client authentication and do away with the "entity" term wh= ich could be causing vagueness. We will also be able to do away with the = PT-TLS Initiator/Responder terminology as well if it's always the PTS that = triggers the client authentication. >=20 > In the common use case where the server has the policy requiring a=20 > client to authenticate, it must send a SASL mechanism message (unless=20 > the client is required to initiate the exchange, which is not what the=20 > spec currently says). >=20 > It might be good to first list out the common use cases we need to=20 > support and the desired behavior, and then make sure that the draft=20 > reflects that. [PS:] Hopefully we don't need to repeat the use cases from RFC 5209 (as we = didn't for PA and PB) but rather ensure that none of those require either s= ide to trigger the client authentication. I'm not aware of a use case that= would require the PTC to trigger the client authentication but we'll look = into it more. > Right now, the draft supports all possible options, and it is not=20 > always clear what is expected to happen in any particular scenario. It=20 > also may be the case that the cost of supporting all these use cases=20 > outweighs the benefit - the more use cases we have, the more testing=20 > needs to be done, and the potential for interoperability issues rises.=20 > But before we reach this conclusion, it would be good to first clarify=20 > what use cases we think we need to support. [PS:] Agreed From Paul_Sangster@symantec.com Mon Dec 12 16:57:15 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF7811E8082 for ; Mon, 12 Dec 2011 16:57:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkNHDQcRqI0Q for ; Mon, 12 Dec 2011 16:57:14 -0800 (PST) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) by ietfa.amsl.com (Postfix) with ESMTP id B2CFA11E807F for ; Mon, 12 Dec 2011 16:57:14 -0800 (PST) X-AuditID: d80ac3f2-b7fb26d00000530c-4a-4ee6a2eab9a7 Received: from tus1smtintpin02.ges.symantec.com (TUS1SMTINTPIN02.ges.symantec.com [192.168.215.102]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id DE.75.21260.AE2A6EE4; Mon, 12 Dec 2011 17:57:14 -0700 (MST) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1smtintpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1RaGgE-0000he-Am; Mon, 12 Dec 2011 16:57:14 -0800 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Mon, 12 Dec 2011 16:57:14 -0800 From: Paul Sangster To: Susan Thomson , Stephen Hanna , "nea@ietf.org" Date: Mon, 12 Dec 2011 16:57:12 -0800 Thread-Topic: [Nea] Extending WG Last Call on PT-TLS I-D Thread-Index: Acx+LUMGWNW3Rd1P1kC7DWASTuuBNgZSy8LgAPMhq48He0WMUA== Message-ID: <6E79D623502C70419A9EAB18E4D274252A9E86481A@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsVyYMX1NN1Xi575GXQdlrX4/LbC4umaKUwW j8+dYnZg9pjyeyOrx5IlP5k8rjddZQ9gjuKySUnNySxLLdK3S+DK2H13DkvBX7GKOX/5Gxin CnUxcnJICJhILN27gA3CFpO4cG89kM3FISTwkVHiWtt0FgjnNaPEyi3/WSGcVYwSZzp2M4K0 sAkYSOw8coodxBYRyJbonXCXGcRmEVCV2HlqKiuILSxgLnH2zjmmLkYOoBoLiZsvfCDKnST6 Vi8CK+EViJJY8bUTbKSQQKFEy9oPYGM4gcZfWtoONp4R6Lrvp9YwgdjMAuISt57MZ4K4WkBi yZ7zzBC2qMTLx/9YIepFJe60r2eEqNeRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoNgvJ2FlI WmYhaZmFpGUBI8sqRpmS0mLD4tyS/NKSgtQKAyO94srcRGBsJesl5+duYgTG1w2uw592MN5Y qniIUYCDUYmHN3DOMz8h1sQyoMpDjBIczEoivLFuQCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8 UpXX/IQE0hNLUrNTUwtSi2CyTBycUg2MIYlmcdv/TnIJZctkDK+Y+TPaMFJrrX9TMNfvJ/df JCtcC+0r3tXxuoT70gOGCY7ym/T5Q14/f6T9X7VzY5z7iVO2u15Ou2nGdWfthNPvHY572dT+ sQioK85yuV6YPJFxepZiQ9ELA69L+3wUln3Pa1MsePTE/q/Q76sfjdfbPD6ywHxLpUm4Ektx RqKhFnNRcSIAQk1VAKsCAAA= 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: Tue, 13 Dec 2011 00:57:15 -0000 Susan, Below are the proposed fixes to the issues you've identified... > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of=20 > Susan Thomson > Sent: Friday, November 04, 2011 3:56 PM > To: Stephen Hanna; nea@ietf.org > Subject: Re: [Nea] Extending WG Last Call on PT-TLS I-D >=20 > A few editorial comments below. >=20 > Thanks > Susan > ------------------ >=20 > Section 1.1: > Remove last sentence. Don't think it is needed anymore. [PS:] Agreed, will remove >=20 >=20 > Section 2.1: > First sentence: > EAP is not necessarily run directly over link layer. Hence, for=20 > generality, remove "link layer oriented bindings such as" from first=20 > sentence. [PS:] Will remove >=20 > Bullet list, first item: > While PT-TLS is full duplex, PB-TNC does not take advantage of this=20 > except for async initiation of posture exchanges. Correct? If so, you=20 > may want to make this clearer. [PS:] This is a list of TCP/IP transport features. It doesn't mean that as= sessment layer protocols make full use of them. We will change to highlig= ht how NEA protocols use this feature to support asynchronous initiation of= posture exchanges within a single connection") as you proposed off-line. >=20 > Section 3.3: > First sentence: Do you mean Posture Broker *Client* here? [PS:] I think this is regarding the second paragraph of 3.3 and we will fix= that. >=20 > Section 3.4.2.2 > First sentence: "it is" -> it's [PS:] Will change to "its" >=20 > 2nd para: First few sentence repetitively uses the word "client". In=20 > one case, I think you mean PT Server, and in other cases, I think one=20 > can drop referral to authentication "of the client" without loss of=20 > clarity. [PS:] Will modify text >=20 > Section 3.6 > Message Type 10: In description, do you mean "recipients of type *10*=20 > or higher ..."? The message type IDs are different from that listed in=20 > Section 6.2. I think Section 6.2 needs to be corrected? [PS:] Good catch, we'll fix this. >=20 > Section 3.7 > Last sentence: Change the SHOULD NOT to a MUST NOT? [PS:] Agreed. Will change to: "Subsequent assessments on the same session MUST use the negotiated version= number and therefore MUST NOT send additional version negotiation messages= ." I don't think there was a compelling reason for the SHOULD NOT that us= ed to be in this sentence. >=20 > Section 3.8.3 > Ist para, 2nd last sentence: Typo "if it believes *it* is" [PS:] Will change this >=20 > Section 3.9 > Two error messages with code #6 [PS:] Thanks, Carolin noticed this too. >=20 > Section 6.2: > See comment on section 3.6. [PS:] Will fix table to match 3.6 >=20 >=20 >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From Paul_Sangster@symantec.com Mon Dec 12 16:59:19 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF31911E8094 for ; Mon, 12 Dec 2011 16:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dd5KLlB3dKU4 for ; Mon, 12 Dec 2011 16:59:19 -0800 (PST) Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) by ietfa.amsl.com (Postfix) with ESMTP id 470A211E807F for ; Mon, 12 Dec 2011 16:59:19 -0800 (PST) X-AuditID: a66201d1-b7f286d00000310f-c9-4ee6a3652dbd Received: from tus1smtintpin01.ges.symantec.com (TUS1SMTINTPIN01.ges.symantec.com [192.168.215.101]) by ecl1mtaoutpex01.symantec.com (Symantec Messaging Gateway) with SMTP id C3.23.12559.563A6EE4; Mon, 12 Dec 2011 19:59:17 -0500 (EST) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1RaGiD-0007qc-2t; Mon, 12 Dec 2011 16:59:17 -0800 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([155.64.220.138]) with mapi; Mon, 12 Dec 2011 16:59:17 -0800 From: Paul Sangster To: Stephen Hanna , "nea@ietf.org" Date: Mon, 12 Dec 2011 16:59:15 -0800 Thread-Topic: Two More PT-TLS Issues Thread-Index: Acyjq/aYwk06roE8RI6ak1+uJ7PbPwVhmHHA Message-ID: <6E79D623502C70419A9EAB18E4D274252A9E86481C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42I5sOJ6qm7q4md+Bnffylt8flth8fjcKWYH Jo8lS34yeVxvusoewBTFZZOSmpNZllqkb5fAlbGj5x1LwW6RioZvS9gaGE8JdDFyckgImEgc fbWDBcIWk7hwbz0biC0k8IZR4lOrZBcjF5D9mlHixfyXbBDOKkaJLdM6WEGq2AQMJHYeOcUO YosIuErM+dzB2MXIwcEioCpx/4QOSFhYQFni/5pjTBAlKhI3735lhLCNJN4/aABr5RWIknh+ Zg4LxGJvidMTD4PZnAI+EvO6V4H1MgId9/3UGjCbWUBc4taT+UwQRwtILNlznhnCFpV4+fgf K0S9qMSd9vWMEPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZ xSiTmpxjmFuSmF9aUpBaYWCoV1yZmwiMo2S95PzcTYzAWFqWxHhxB+OFw7qHGAU4GJV4eMPn PfMTYk0sA6o8xCjBwawkwhvrBhTiTUmsrEotyo8vKs1JLT7EKM3BoiTO61d5zU9IID2xJDU7 NbUgtQgmy8TBKdXAuO0EM5Md61vGvh+WZd02sdG3Z990/8yQsvOm6HHlKKNfXYWSkl9LBQMv 8mvcqD8b+qytYrrxiSeKLCkTnnjzdk198bXHqYS5d6bYHy2rK8nNiYvsvko3tGXNnMlkF/Wi I2jBPw6X079mLa5VqVh/af69kzmqYueumaxzq7Koyr2i9uTSc+2JSizFGYmGWsxFxYkAduZR VqECAAA= Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 00:59:20 -0000 Steve, Comments and proposals are in-lined... > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of=20 > Stephen Hanna > Sent: Tuesday, November 15, 2011 7:34 AM > To: nea@ietf.org > Subject: [Nea] Two More PT-TLS Issues >=20 > In preparing the slides for this week's NEA meeting, the chairs and=20 > editors have uncovered two more PT-TLS issues that should be resolved.=20 > I'm sorry that these weren't raised during WGLC but it's good that=20 > they have been smoked out by the process and it's best to get them=20 > 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=20 > and the NEA Server is the TLS Client. In this mode, PT-TLS requires=20 > that the NEA Client use an X.509 certificate to authenticate itself=20 > during the TNC handshake (TLS server auth). > No requirements are placed on how the NEA Server authenticates itself=20 > in this mode, although such authentication is clearly highly=20 > desirable. Since the NEA Server generally has an X.509 certificate for=20 > the more common situation where the NEA Client is the TNC Client, the=20 > simplest way to resolve this seems to be to require the NEA Server to=20 > use its > X.509 certificate to authenticate itself during the TLS handshake,=20 > performing TLS mutual auth. > This avoids the need for the NEA Client to support authenticating the=20 > NEA Server with SASL, simplifying implementation and testing. [PS:] Agreed. I believe it was discussed that the NEA Server could still u= se the SASL authentication messages to further authentication the NEA Clien= t. >=20 > In the NEA meeting at IETF 81, Trevor Freeman asked why PT-TLS doesn't=20 > include a way to bind the inner SASL authentication to the TLS tunnel.=20 > Without that, an attacker could forward a SASL authentication through=20 > multiple PT-TLS tunnels. We agreed to figure out how to do channel=20 > binding and put that in PT-TLS. > However, that isn't present in the current draft. > It should be added. [PS:] Correct, section 3.8.1 was updated based upon the IETF 81 discussion = to call out SASL GS2 mechanisms that can support channel bindings. We will= add more detail as to how this is integrated with PT-TLS to bind the chann= els for common GS2 mechanisms.=20 >=20 > Thanks, >=20 > Steve >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From shanna@juniper.net Mon Dec 19 10:39:11 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 9FB861F0C5C for ; Mon, 19 Dec 2011 10:39:11 -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 eCrGe4cZPQmB for ; Mon, 19 Dec 2011 10:39:11 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id D253B1F0C56 for ; Mon, 19 Dec 2011 10:39:10 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKTu+EzF28OdiovechVRkxuy72YGit8vhk@postini.com; Mon, 19 Dec 2011 10:39:10 PST Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 19 Dec 2011 10:36:58 -0800 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 19 Dec 2011 10:36:58 -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, 19 Dec 2011 13:36:56 -0500 From: Stephen Hanna To: Paul Sangster , "nea@ietf.org" Date: Mon, 19 Dec 2011 13:36:54 -0500 Thread-Topic: Two More PT-TLS Issues Thread-Index: Acyjq/aYwk06roE8RI6ak1+uJ7PbPwVhmHHAAVKFz1A= Message-ID: References: <6E79D623502C70419A9EAB18E4D274252A9E86481C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> In-Reply-To: <6E79D623502C70419A9EAB18E4D274252A9E86481C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 18:39:11 -0000 Paul, I'm happy with the changes that you suggested below to address these comments. And this is consistent with what was discussed at the NEA meeting in Taipei. If anyone has any concerns about these resolutions, please raise them now. And if no concerns are raised, let's consider this to be the WG consensus and have Paul or the other PT-TLS editors make these changes. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Paul Sangster > Sent: Monday, December 12, 2011 7:59 PM > To: Stephen Hanna; nea@ietf.org > Subject: Re: [Nea] Two More PT-TLS Issues >=20 > Steve, >=20 > Comments and proposals are in-lined... >=20 > > -----Original Message----- > > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > > Stephen Hanna > > Sent: Tuesday, November 15, 2011 7:34 AM > > To: nea@ietf.org > > Subject: [Nea] Two More PT-TLS Issues > > > > 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. > > > > 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. >=20 > [PS:] Agreed. I believe it was discussed that the NEA Server could > still use the SASL authentication messages to further authentication > the NEA Client. >=20 > > > > 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. >=20 > [PS:] Correct, section 3.8.1 was updated based upon the IETF 81 > discussion to call out SASL GS2 mechanisms that can support channel > bindings. We will add more detail as to how this is integrated with > PT-TLS to bind the channels for common GS2 mechanisms. >=20 > > > > Thanks, > > > > Steve > > > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www.ietf.org/mailman/listinfo/nea >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From blueroofmusic@gmail.com Mon Dec 19 11:11:20 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 367AD11E8097 for ; Mon, 19 Dec 2011 11:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXUS7dQdiTSA for ; Mon, 19 Dec 2011 11:11:19 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id CC97B11E8081 for ; Mon, 19 Dec 2011 11:11:18 -0800 (PST) Received: by werb14 with SMTP id b14so1740138wer.31 for ; Mon, 19 Dec 2011 11:11:18 -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=+qTXdOTBSFCuZx5xaxvTfeiSrs96VeA+iZ9YrLIxtfM=; b=NeuHSeWp2oXPwpcjluxMk2+TOd2Xy7xlBqtV1NapeGTkcvewwd95P73ttGyV4EFWGJ /5pj/t/pB37s/eRmPIySiUnyihHXR4Hm6WC1wSmtwDHeiM60YBDUHGGUPjo7lwmPFYKq pSDNRxF6tOA9/bqsrPMQ88u9bvrC3xoYD/Y6w= MIME-Version: 1.0 Received: by 10.216.139.140 with SMTP id c12mr7666076wej.26.1324321877893; Mon, 19 Dec 2011 11:11:17 -0800 (PST) Received: by 10.223.57.130 with HTTP; Mon, 19 Dec 2011 11:11:17 -0800 (PST) In-Reply-To: References: <6E79D623502C70419A9EAB18E4D274252A9E86481C@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Date: Mon, 19 Dec 2011 14:11:17 -0500 Message-ID: From: Ira McDonald To: Stephen Hanna , Ira McDonald Content-Type: multipart/alternative; boundary=0016e6ddfebe19a12e04b476b736 Cc: "nea@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 19:11:20 -0000 --0016e6ddfebe19a12e04b476b736 Content-Type: text/plain; charset=ISO-8859-1 Hi, I have no issues with Paul's suggested resolutions - thanks for the thoughtful responses Paul. 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, Dec 19, 2011 at 1:36 PM, Stephen Hanna wrote: > Paul, > > I'm happy with the changes that you suggested below to > address these comments. And this is consistent with > what was discussed at the NEA meeting in Taipei. > > If anyone has any concerns about these resolutions, > please raise them now. And if no concerns are raised, > let's consider this to be the WG consensus and have > Paul or the other PT-TLS editors make these changes. > > Thanks, > > Steve > > > -----Original Message----- > > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > > Paul Sangster > > Sent: Monday, December 12, 2011 7:59 PM > > To: Stephen Hanna; nea@ietf.org > > Subject: Re: [Nea] Two More PT-TLS Issues > > > > Steve, > > > > Comments and proposals are in-lined... > > > > > -----Original Message----- > > > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > > > Stephen Hanna > > > Sent: Tuesday, November 15, 2011 7:34 AM > > > To: nea@ietf.org > > > Subject: [Nea] Two More PT-TLS Issues > > > > > > 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. > > > > > > 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. > > > > [PS:] Agreed. I believe it was discussed that the NEA Server could > > still use the SASL authentication messages to further authentication > > the NEA Client. > > > > > > > > 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. > > > > [PS:] Correct, section 3.8.1 was updated based upon the IETF 81 > > discussion to call out SASL GS2 mechanisms that can support channel > > bindings. We will add more detail as to how this is integrated with > > PT-TLS to bind the channels for common GS2 mechanisms. > > > > > > > > Thanks, > > > > > > Steve > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > --0016e6ddfebe19a12e04b476b736 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I have no issues with Paul's suggested resolutions - thanks = for
the thoughtful responses Paul.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foun= dation 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://si= tes.google.com/site/highnorthinc
mailto:blueroo= fmusic@gmail.com
Winter=A0 579 Park Place=A0 Saline, MI=A0 48176=A0 = 734-944-0094
Summer=A0 PO Box 221=A0 Grand Marais, MI 49839=A0 906-494-2= 434



On Mon, Dec 19, 2011 at 1:36 PM, Stephen= Hanna <shanna@j= uniper.net> wrote:
Paul,

I'm happy with the changes that you suggested below to
address these comments. And this is consistent with
what was discussed at the NEA meeting in Taipei.

If anyone has any concerns about these resolutions,
please raise them now. And if no concerns are raised,
let's consider this to be the WG consensus and have
Paul or the other PT-TLS editors make these changes.

Thanks,

Steve

> -----Original Message-----
> From: nea-bounces@ietf.org= [mailto:nea-bounces@ietf.org] = On Behalf Of
> Paul Sangster
> Sent: Monday, December 12, 2011 7:59 PM
> To: Stephen Hanna; nea@ietf.org > Subject: Re: [Nea] Two More PT-TLS Issues
>
> Steve,
>
> Comments and proposals are in-lined...
>
> > -----Original Message-----
> > From: nea-bounces@ietf.or= g [mailto:nea-bounces@ietf.org<= /a>] On Behalf Of
> > Stephen Hanna
> > Sent: Tuesday, November 15, 2011 7:34 AM
> > To: nea@ietf.org
> > Subject: [Nea] Two More PT-TLS Issues
> >
> > In preparing the slides for this week's NEA meeting, the chai= rs 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= 9;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 meeti= ng.
> >
> > First, PT-TLS supports a mode where the NEA Client is the TLS Ser= ver
> > and the NEA Server is the TLS Client. In this mode, PT-TLS requir= es
> > that the NEA Client use an X.509 certificate to authenticate itse= lf
> > during the TNC handshake (TLS server auth).
> > No requirements are placed on how the NEA Server authenticates it= self
> > in this mode, although such authentication is clearly highly
> > desirable. Since the NEA Server generally has an X.509 certificat= e
> 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 Serve= r 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.
>
> [PS:] Agreed. =A0I believe it was discussed that the NEA Server could<= br> > still use the SASL authentication messages to further authentication > the NEA Client.
>
> >
> > 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 thr= ough
> > multiple PT-TLS tunnels. We agreed to figure out how to do channe= l
> > binding and put that in PT-TLS.
> > However, that isn't present in the current draft.
> > It should be added.
>
> [PS:] Correct, section 3.8.1 was updated based upon the IETF 81
> discussion to call out SASL GS2 mechanisms that can support channel > bindings. =A0We will add more detail as to how this is integrated with=
> PT-TLS to bind the channels for common GS2 mechanisms.
>
> >
> > Thanks,
> >
> > Steve
> >
> > _______________________________________________
> > 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
_______________________________________________
Nea mailing list
Nea@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/nea

--0016e6ddfebe19a12e04b476b736-- From sethomso@cisco.com Wed Dec 21 07:24:21 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 DA96921F867F for ; Wed, 21 Dec 2011 07:24:21 -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 XqcCYBf2+qzM for ; Wed, 21 Dec 2011 07:24:21 -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 1A68421F85A8 for ; Wed, 21 Dec 2011 07:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=3175; q=dns/txt; s=iport; t=1324481061; x=1325690661; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=bEBgL6udi9b9mvWmXwxfQGBSvbbUUEuHugstFCHYsiA=; b=jQNCoVPw1j+d+ZP63N0JLkM2Ema4+4bGVmOzjDWxDDqGhk4i9JwHFdeW jiHwczo1FZm51CpAWybPruk36JFSgKN2zoqnFnKXUNusJ+i0MlrEGzv8k PGV2IfqG2MOFl4l7i0JJV3NJIeEQDJ4EB4blKDl6j6/VoIMUUUbvIxDnV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAAEX58U6tJV2c/2dsb2JhbABDm0OQV4EFgXIBAQEDAQEBAQ8BFBMCATEQBwYBCBEEAQEoLh8JCAEBBAESIodYCJkGAZ5KBIwPBIg3jEiSUA X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; d="scan'208";a="45865704" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 21 Dec 2011 15:24:20 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pBLFOKvn008617; Wed, 21 Dec 2011 15:24:20 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, 21 Dec 2011 09:24:20 -0600 Received: from 10.116.64.99 ([10.116.64.99]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Dec 2011 15:24:20 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 21 Dec 2011 10:23:45 -0500 From: Susan Thomson To: Paul Sangster , Stephen Hanna , "nea@ietf.org" Message-ID: Thread-Topic: [Nea] Extending WG Last Call on PT-TLS I-D Thread-Index: Acx+LUMGWNW3Rd1P1kC7DWASTuuBNgZSy8LgAPMhq48He0WMUAGwnhnu In-Reply-To: <6E79D623502C70419A9EAB18E4D274252A9E86481A@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Dec 2011 15:24:20.0271 (UTC) FILETIME=[9C5603F0:01CCBFF4] 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: Wed, 21 Dec 2011 15:24:22 -0000 Hi Paul Thanks for addressing these comments. Looks good to me. Susan On 12/12/11 7:57 PM, "Paul Sangster" wrote: > Susan, > > Below are the proposed fixes to the issues you've identified... > >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of >> Susan Thomson >> Sent: Friday, November 04, 2011 3:56 PM >> To: Stephen Hanna; nea@ietf.org >> Subject: Re: [Nea] Extending WG Last Call on PT-TLS I-D >> >> A few editorial comments below. >> >> Thanks >> Susan >> ------------------ >> >> Section 1.1: >> Remove last sentence. Don't think it is needed anymore. > > [PS:] Agreed, will remove > >> >> >> 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. > > [PS:] Will remove > >> >> 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. > > [PS:] This is a list of TCP/IP transport features. It doesn't mean that > assessment layer protocols make full use of them. We will change to > highlight how NEA protocols use this feature to support asynchronous > initiation of posture exchanges within a single connection") as you proposed > off-line. > >> >> Section 3.3: >> First sentence: Do you mean Posture Broker *Client* here? > > [PS:] I think this is regarding the second paragraph of 3.3 and we will fix > that. > >> >> Section 3.4.2.2 >> First sentence: "it is" -> it's > > [PS:] Will change to "its" > >> >> 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. > > [PS:] Will modify text > >> >> 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? > > [PS:] Good catch, we'll fix this. > >> >> Section 3.7 >> Last sentence: Change the SHOULD NOT to a MUST NOT? > > [PS:] Agreed. Will change to: > "Subsequent assessments on the same session MUST use the negotiated version > number and therefore MUST NOT send additional version negotiation messages." > I don't think there was a compelling reason for the SHOULD NOT that used to be > in this sentence. > >> >> Section 3.8.3 >> Ist para, 2nd last sentence: Typo "if it believes *it* is" > > [PS:] Will change this > >> >> Section 3.9 >> Two error messages with code #6 > > [PS:] Thanks, Carolin noticed this too. > >> >> Section 6.2: >> See comment on section 3.6. > > [PS:] Will fix table to match 3.6 > >> >> >> >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea From sethomso@cisco.com Wed Dec 21 07:24:48 2011 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D670C21F8801 for ; Wed, 21 Dec 2011 07:24:48 -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 4VutWTqzMQH2 for ; Wed, 21 Dec 2011 07:24:48 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBE721F86FF for ; Wed, 21 Dec 2011 07:24:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sethomso@cisco.com; l=3725; q=dns/txt; s=iport; t=1324481088; x=1325690688; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=kxk5vAEjFsQAQTPYJUi3N23DXOtA7tQzHZ3bMIvsxEE=; b=W1sS7QDOb8KAwdvi4a+W2LiD+2+2QP1AvYpx+QeUl+bCbyi7SQL+wOMY UnI86io2kyVlCWECAqscAQAs5GXaaquIxzqXnTUuB1WGg4qbMUom1Xk2i 7eD7c+iZswRKilsRU24Npls4k9iYOVIGeatgLHWTmPeEs3CWepWWMNouE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooAAEX58U6tJXHB/2dsb2JhbABDm0OQV4EFgXIBAQEDARIBJwIBQQcGAQgRBAEBKE0JCAEBBAESIodYmQ4Bnk6MDwSIN4xIklA X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; d="scan'208";a="45847575" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 21 Dec 2011 15:24:47 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pBLFOknC017627; Wed, 21 Dec 2011 15:24:46 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); Wed, 21 Dec 2011 09:24:46 -0600 Received: from 10.116.64.99 ([10.116.64.99]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 21 Dec 2011 15:24:46 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 21 Dec 2011 10:24:45 -0500 From: Susan Thomson To: Paul Sangster , "nea@ietf.org" Message-ID: Thread-Topic: Comment re PT-TLS and SASL mechanism negotiation Thread-Index: AcyjMJdbz6YbGlBUk0inK5Tu++BMDgWASlqQAbC6lOE= In-Reply-To: <6E79D623502C70419A9EAB18E4D274252A9E864813@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Dec 2011 15:24:46.0535 (UTC) FILETIME=[ABFD9570:01CCBFF4] Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 15:24:48 -0000 Hi Paul Thanks for the response. Inline ... On 12/12/11 7:54 PM, "Paul Sangster" wrote: > Susan, > > Comments and proposed remedies are discussed below... > >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of >> Susan Thomson >> Sent: Monday, November 14, 2011 4:51 PM >> To: nea@ietf.org >> Subject: [Nea] Comment re PT-TLS and SASL mechanism negotiation >> >> 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). > > [PS:] In section 3.4.2.2, the first sentence says: > > "Once a TLS session has been established between Posture Transport Client and > Posture Transport Server, the PT-TLS Initiator sends a Version Request Message > indicating it is supported PT-TLS protocol version range." > > Because either side may have initiated the TLS Setup Phase (e.g. NEA Client or > Server could have triggered the TLS session), we use the term "PT-TLS > Initiator". This means who ever initiated the PT-TLS session goes first for > version negotiation (not a race condition). > > However for section 3.8.3 (SASL authentication), the -01 draft allows either > party to initiate without a deadlock. However this does introduce complexity > so unless a use case for either side initiating the client (currently > "entity") authentication then we will modify section 3.8 to just have the PTS > initiate the client authentication and do away with the "entity" term which > could be causing vagueness. We will also be able to do away with the PT-TLS > Initiator/Responder terminology as well if it's always the PTS that triggers > the client authentication. > [ST] Agree that the text will become simpler to specify with just having the PTS initiate. >> >> 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. > > [PS:] Hopefully we don't need to repeat the use cases from RFC 5209 (as we > didn't for PA and PB) but rather ensure that none of those require either side > to trigger the client authentication. I'm not aware of a use case that would > require the PTC to trigger the client authentication but we'll look into it > more. > [ST] Your last sentence seemed to be the sentiment of the WG at the last IETF meeting as well. We would just need to be sure that whatever we specify is sufficient for addressing the use case in both directions (assuming we continue to support SASL authn in both directions), i.e when NEA server is playing role of PTS server and when NEA client plays that role. Thanks Susan >> 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. > > [PS:] Agreed >