From jsalowey@cisco.com Tue May 1 22:12:49 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC8121E8028 for ; Tue, 1 May 2012 22:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieFGAgTy4OqV for ; Tue, 1 May 2012 22:12:49 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2F27D21E8027 for ; Tue, 1 May 2012 22:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=3431; q=dns/txt; s=iport; t=1335935569; x=1337145169; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=voXluv1T6L/iTKGx8TPlm6fXzp0q2ZDnbn5p24sGPGA=; b=T2hTb2dgxyXWyBz6IUA2SXXoHnd7SKECMJ6UPnSW8JOnVkmqd+MbtLBF ilEbfi5PN3ju9j+Xd/6ybcNl7E9C2Y6E8F9zZ/Mh7Tv2Vzj6nJxXjF6++ Jeg64SHxlkZtRZR4Rh7/wPYVki+lvWM/v6f6dQkvC4rK3OcrOU52oUeHn 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAGAATCoE+rRDoI/2dsb2JhbABBA4MdrF2DAoEHggkBAQEDAQEBAQ8BWwsFCwtGJzAGEyKHZgQMmj2fT41egkdjBIhkjRqBEYRliGOBaYMI X-IronPort-AV: E=Sophos;i="4.75,514,1330905600"; d="scan'208";a="40518009" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 02 May 2012 05:12:49 +0000 Received: from [10.33.251.111] ([10.33.251.111]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q425CmjA014821; Wed, 2 May 2012 05:12:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Joe Salowey In-Reply-To: Date: Tue, 1 May 2012 22:12:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Clifford Kahn X-Mailer: Apple Mail (2.1084) Cc: "nea@ietf.org" Subject: Re: [Nea] Review comments on Asokan Attack Analysis 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 May 2012 05:12:50 -0000 Hi Clifford, Thanks for taking time to review the document and provide good comments. On Apr 28, 2012, at 8:36 PM, Clifford Kahn wrote: > Hello. I reviewed the latest version of the NEA Asokan Attack = Analysis at http://datatracker.ietf.org/doc/draft-ietf-nea-asokan/.=20 > =20 > I found it strong right up to the conclusions, but them I found = unclear. > =20 > =D8 The recommendations for addressing the NEA Asokan Attack are as = follows: > =20 > To whom are these recommendations? To implementers, or to writers of = specs? =20 > =20 [Joe] Mostly to writers of specs, but it should also help implementers = understand the motivation behind the specification.=20 > =D8 1. Make use of cryptographic binding, however binding identities = of the tunnel endpoints in the EMA may be useful. > =20 > The =93however=94 is confusing. I think it means that one should make = use of cryptographic binding, and that in addition binding identities of = the tunnel endpoints in the EMA may be useful. Whether I got it right = or not, please consider rephrasing. [Joe] Good catch, this should be reworded and the bit about the tunnel = identities should be removed. How about: "Make use of cryptographic binding to protect the integrity of the TLS = tunnel. "=20 > =20 > =D8 2. Use the same mechanism in L2 and L3 PT transports that make = use of TLS (e.g. PT-TLS and PT-EAP). > =20 > I take it that =93the same mechanism=94 refers to the two mechanisms = in recommendation 1. But will others take it that way?=20 > =20 > Doesn=92t recommendation 1 entail recommendation 2? Why is 2 here? = Since 2 is here, I take it that 1 must have in mind transports other = than the ones 2 mentions. But 1 doesn=92t say what transports it has in = mind =96 or I don=92t understand. > =20 [Joe] How about: "Use the same cryptographic binding mechanism in L2 and L3 TLS-based PT = transports (e.g. PT-TLS and PT-EAP)." > =D8 3. Neither TLS endpoint can be in sole control of the TLS = pre-master secret. This is not strictly necessary when tls-unique = channel binding values are used. > =20 > I=92m a bit confused by the double negative. The first sentence is a = negative, and the second negates that negative.=20 > =20 > I think it means that when TLS-unique channel binding values are used, = it=92s kind of OK for one TLS endpoint to be in sole control of the TLS = pre-master secret. Whether I got it right or not, please consider = rephrasing. > =20 [Joe] Yes, that is correct. The text is a bit confusing and = unnecessary since we recommend use of TLS unique, I think we should = delete this item. we could add to 4: "The preferred approach is to use the tls-unique channel binding data = from RFC 5929 [9]. The tls-unique value will be made available to the = EMA that will use it. This approach can utilize any TLS cipher suite = based on a strong cipher algorithm." (perhaps this just opens the can of worms of what a strong cipher = algorithm is.) > I hope that helps. > =20 > Thanks for this important work. > Clifford Kahn > =20 > Clifford Kahn > Pulse BU > 1-978-589-0252 (or x20252) > =20 > > =20 > =20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From cliffordk@juniper.net Wed May 2 12:32:24 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EED521E80B7 for ; Wed, 2 May 2012 12:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.794 X-Spam-Level: X-Spam-Status: No, score=-5.794 tagged_above=-999 required=5 tests=[AWL=0.805, BAYES_00=-2.599, 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 I-YI9C7pZAKb for ; Wed, 2 May 2012 12:32:24 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 4F64C21E8056 for ; Wed, 2 May 2012 12:32:23 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT6GLxjZ9p5uaS1iuYQjKoAvRgdvqBZOv@postini.com; Wed, 02 May 2012 12:32:23 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 2 May 2012 12:30:19 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 2 May 2012 12:30:19 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 2 May 2012 15:30:18 -0400 From: Clifford Kahn To: Joe Salowey Date: Wed, 2 May 2012 15:30:17 -0400 Thread-Topic: [Nea] Review comments on Asokan Attack Analysis Thread-Index: Ac0oIjkG4Itw2PGGQOK1BtgMuFryqwAdD5Ww Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 02 May 2012 12:54:50 -0700 Cc: "nea@ietf.org" Subject: Re: [Nea] Review comments on Asokan Attack Analysis 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 May 2012 19:32:24 -0000 Hi Joe. > Thanks for taking time to review the document and provide good comments. Glad to help. > On Apr 28, 2012, at 8:36 PM, Clifford Kahn wrote: =20 > =D8 The recommendations for addressing the NEA Asokan Attack are as foll= ows: > =20 > To whom are these recommendations? To implementers, or to writers of spe= cs? =20 > =20 [Joe] Mostly to writers of specs, but it should also help implementers unde= rstand the motivation behind the specification.=20 [Cliff] That makes sense. So the recommendations are for protocols. The re= commendations in most IETF specs are for implementations of protocols, whic= h is a little bit different. It may help to reword each recommendation som= ething like: "Protocols should make use of cryptographic binding ..." > =D8 1. Make use of cryptographic binding, however binding identities of = the tunnel endpoints in the EMA may be useful. > =20 > The "however" is confusing. I think it means that one should make use of= cryptographic binding, and that in addition binding identities of the tunn= el endpoints in the EMA may be useful. Whether I got it right or not, plea= se consider rephrasing. [Joe] Good catch, this should be reworded and the bit about the tunnel iden= tities should be removed. How about: "Make use of cryptographic binding to protect the integrity of the TLS tunn= el. "=20 [Cliff] That works for me. > =20 > =D8 2. Use the same mechanism in L2 and L3 PT transports that make use o= f TLS (e.g. PT-TLS and PT-EAP). > =20 > I take it that "the same mechanism" refers to the two mechanisms in recom= mendation 1. But will others take it that way?=20 > =20 > Doesn't recommendation 1 entail recommendation 2? Why is 2 here? Since = 2 is here, I take it that 1 must have in mind transports other than the one= s 2 mentions. But 1 doesn't say what transports it has in mind - or I don'= t understand. > =20 [Joe] How about: "Use the same cryptographic binding mechanism in L2 and L3 TLS-based PT tra= nsports (e.g. PT-TLS and PT-EAP)." [Cliff] I don't think that helps me. Sorry to be thick. Doesn't recommend= ation 1 cover all transports? Isn't recommendation 2 a corollary and redun= dant? =20 If recommendation 1 does not cover all transports, I suggest making it say = which transports it covers. If recommendation 1 does cover all transports = and recommendation 2 is a corollary, you might either delete recommendation= 2 or make recommendation 2 begin "In particular": "In particular, L2 and L3 TLS-based PT transports ... should use cryptogra= phic binding ..." =20 That would clear up the relationship between recommendations 1 and 2.=20 > =D8 3. Neither TLS endpoint can be in sole control of the TLS pre-master= secret. This is not strictly necessary when tls-unique channel binding va= lues are used. > =20 > I'm a bit confused by the double negative. The first sentence is a negat= ive, and the second negates that negative.=20 > =20 > I think it means that when TLS-unique channel binding values are used, it= 's kind of OK for one TLS endpoint to be in sole control of the TLS pre-mas= ter secret. Whether I got it right or not, please consider rephrasing. > [Joe] Yes, that is correct. The text is a bit confusing and unnecessary s= ince we recommend use of TLS unique, I think we should delete this item. w= e could add to 4: "The preferred approach is to use the tls-unique channel binding data from = RFC 5929 [9]. The tls-unique value will be made available to the EMA that = will use it. This approach can utilize any TLS cipher suite based on a st= rong cipher algorithm." (perhaps this just opens the can of worms of what a strong cipher algorithm= is.) [Cliff] I like the simplification and the clarity. If one's cipher suite is not strong enough and an attacker cracks it, then = all bets are off. That's always true. I don't see why a strong cipher sui= te is more needed here than it is in other places. If you agree with that,= you might want to delete "based on a strong cipher algorithm". =20 Thanks for considering my comments. Cliff > =20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From latze@angry-red-pla.net Fri May 4 05:07:05 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D9321F860B for ; Fri, 4 May 2012 05:07:05 -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 6jvCpvkbQ1QN for ; Fri, 4 May 2012 05:07:04 -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 6ED8A21F8622 for ; Fri, 4 May 2012 05:07:03 -0700 (PDT) Received: from 110-229.194-178.cust.bluewin.ch ([178.194.229.110] helo=[192.168.1.128]) by thuvia.angry-red-pla.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1SQHHp-0001sf-Fr for nea@ietf.org; Fri, 04 May 2012 14:07:01 +0200 Message-ID: <4FA3C664.4000208@angry-red-pla.net> Date: Fri, 04 May 2012 14:07:00 +0200 From: Carolin Latze User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111110 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] WGLC on NEA Asokan Attack Analysis 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 May 2012 12:07:05 -0000 Hi I have just one comment. In the introduction it is said that "The NEA WG has included several of these countermeasures in PT-TLS [5] and PT-EAP [6]" The first question that came into my mind was "and why not all of them?" :-) So maybe it would make sense to describe the reasoning behind the selection of the countermeasures that will be used in PT-TLS and PT-EAP. regards Carolin On 04/27/2012 04:58 PM, Stephen Hanna wrote: > As previously agreed, the NEA Asokan Attack Analysis > has been changed into a NEA WG draft. This draft has > received several years of discussion and review in > our WG, dating back to its initial publication as > draft-salowey-nea-asokan-00.txt back in October 2010. > > We agreed to make this document a WG draft because > we found its analysis essential to describing the need > for TLS channel bindings to prevent Asokan attacks. > Both PT-TLS and PT-EAP contain informational but > important references to this document. For those > documents to be fully understood, it's essential > for the NEA Asokan Attack Analysis to become an > informational RFC. > > Therefore, I'd like to ask all active NEA WG > participants to please review the latest draft > of the NEA Asokan Attack Analysis and to send > comments, corrections, or questions to the WG > list. Please complete this Working Group Last > Call review within two weeks (by 1600 GMT on > Friday, May 11 - noon EDT or 9 AM PDT). If any > substantive issues have been raised, we'll get > those resolved. And if there's WG consensus to > ask the IESG to advance the document to > Informational RFC status, we'll do that. > > If you don't have any comments on the document > but you agree that it should advance to > Informational RFC status, you can just send > an email in response to this one saying so. > And if you think that it should not advance, > please send an email saying that also. These > emails will be useful in judging WG consensus. > > Here's a link to the draft for review: > > http://datatracker.ietf.org/doc/draft-ietf-nea-asokan/ > > At only eight pages in length (and really only > four pages of content), I think you will find it > an easy but interesting read. In any event, you > should learn something. And something quite > relevant to NEA. If you've already read the > document before, a quick skim should help you > confirm that you're comfortable with the latest > version (or not). Your brief review and comment > would be greatly appreciated. > > Thanks in advance for your help, > > Steve > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > From shanna@juniper.net Mon May 7 20:40:00 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB8D21F85F1 for ; Mon, 7 May 2012 20:40:00 -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 IA3g-hdHxxbc for ; Mon, 7 May 2012 20:40:00 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by ietfa.amsl.com (Postfix) with ESMTP id B93D121F85DD for ; Mon, 7 May 2012 20:39:59 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKT6iVj6Rs+3SNNXdGcFJNG0mfwdhJFybd@postini.com; Mon, 07 May 2012 20:39:59 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 7 May 2012 20:39:59 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 7 May 2012 23:39:58 -0400 From: Stephen Hanna To: "nea@ietf.org" Date: Mon, 7 May 2012 23:39:56 -0400 Thread-Topic: A Few Glitches in PT-TLS Thread-Index: Ac0lLcI/CLVNCRiVSfigSbsPABhTegHnbWaw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Nea] A Few Glitches in PT-TLS 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 May 2012 03:40:00 -0000 While preparing the Document Shepherd Write-Up for PT-TLS, I noticed a few minor errors in the document. * The second sentence of the Introduction says the document evaluates itself relative to the requirements in RFC 5209 and RFC 5973. That's no longer true since you removed Appendix A. So I think this sentence should be removed. You might want to mention later in the document (maybe in section 1.1) that the document was evaluated against the requirements in those specs and that it passed with flying colors. * Section 6 refers to "PT-TLS Auth Types". These aren't mentioned anywhere else in the spec so I think this mention should be deleted. Also, the last paragraph in section 6.1 says "the following three sections provide guidance to the IANA" but there are only two following sections in the IANA Considerations. I think that should say "two sections". * The "Invalid Parameter error code" is referred to widely but not listed in section 3.9 or section 6.3. Probably it should be added. * The "Authentication Needed" error code is no longer needed, I think. In fact, it's not referred to anywhere, although I think that the "Authentication Required" error code that's mentioned at the end of section 3.8.3 is it. But we no longer need it because section 3.8.3 now says "the NEA Client MUST NOT transition to the PT-TLS Data Transport phase until it receives" a SASL Mechanisms TLV with no mechanisms. So there's no way that a NEA Client could send a NEA assessment message before the completion of the client authentication. * Error code 5 has a name of "Invalid Message" in section 3.9 and many other places but it's named "Invalid Message Error" in section 6.3. I think that "Invalid Message" is a better name and it's certainly more widely used so let's just fix section 6.3. * Section 6.3 talks about an "Error Information" field that's not mentioned anywhere else. I think we should just delete that. Could the document editors please review this list? If you agree these are minor errors, please fix them. I want the document that we send to the IESG to be of the highest quality. Thanks, Steve From Paul_Sangster@symantec.com Tue May 8 09:32:19 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B52B21F84DC for ; Tue, 8 May 2012 09:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9bf6av0f4OBx for ; Tue, 8 May 2012 09:32:18 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6961B21F8499 for ; Tue, 8 May 2012 09:32:18 -0700 (PDT) X-AuditID: d80ac3f1-b7f686d000007b77-ce-4fa94a91a5c2 Received: from tus1smtintpin01.ges.symantec.com (TUS1SMTINTPIN01.ges.symantec.com [192.168.215.101]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 85.29.31607.19A49AF4; Tue, 8 May 2012 16:32:17 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by tus1smtintpin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1SRnKb-0004Lv-1H; Tue, 08 May 2012 16:32:09 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([169.254.188.134]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Tue, 8 May 2012 09:31:32 -0700 From: Paul Sangster To: Stephen Hanna , "nea@ietf.org" Date: Tue, 8 May 2012 09:31:30 -0700 Thread-Topic: A Few Glitches in PT-TLS Thread-Index: Ac0lLcI/CLVNCRiVSfigSbsPABhTegHnbWawABsRVAA= Message-ID: <6E79D623502C70419A9EAB18E4D274252B87CC95CB@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+NgFprAIsWRmVeSWpSXmKPExsVyYMX1VN2JXiv9DTZ+tbT4/LbC4vG5U8wO TB5Llvxk8rjedJU9gCmKyyYlNSezLLVI3y6BK+NmyyW2gg3iFWc3vGFuYJwu1MXIySEhYCIx /dBmJghbTOLCvfVsXYxcHEICHxklzh78wA7hvGaUOPjpACuEs4pRYsv8VjaQFjYBA4mdR06x g9giAq4Scz53MILYLAIqEkeWXgIbKyygKrHp3FJGiBo1ib/XprJB2FYSs642gPXyCkRJHLmy FywuJOAtceb5F7B6TgEfiR2zDoLNYQQ67/upNWA2s4C4xK0n86HOFpBYsuc8M4QtKvHy8T9W iHpRiTvt6xkh6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YJjCKzUIydhaSlllIWmYhaVnAyLKK UaaktNiwOLckv7SkILXCwFCvuDI3ERhLyXrJ+bmbGIHxdIPr8McdjNeXKh5iFOBgVOLhbXRd 6S/EmlgGVHmIUYKDWUmEd5Y6UIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvN6El/kIC6Yklqdmp qQWpRTBZJg5OqQbGI69PJRfPXOPDd8xo2cUS9y/zV3F5TPF7kdfItcu1M/rxRrZtqhXzD/rH KnDUygvbLr77jVW/SuONbbGpi0Pr17iSLd7VEo/P9SbIOiRckotZPyGbTXGC+NTkb93+c1zv rHZkuZEzI/xZ6dJ/d/dmKPP82MIRxXPmdcnXGS0Vn08mC1VPkJFSYinOSDTUYi4qTgQAPPcr 4qMCAAA= Subject: Re: [Nea] A Few Glitches in PT-TLS 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 May 2012 16:32:19 -0000 Steve, Thanks for catching these minor issues. I agree they should be addressed r= ight away so the IESG version is of the highest quality. We can produce a = -04 draft addressing these which could be sent to the IESG. Paul > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Stephen Hanna > Sent: Monday, May 07, 2012 8:40 PM > To: nea@ietf.org > Subject: [Nea] A Few Glitches in PT-TLS >=20 > While preparing the Document Shepherd Write-Up for PT-TLS, I noticed a > few minor errors in the document. >=20 > * The second sentence of the Introduction says the > document evaluates itself relative to the > requirements in RFC 5209 and RFC 5973. That's no > longer true since you removed Appendix A. So > I think this sentence should be removed. >=20 > You might want to mention later in the document > (maybe in section 1.1) that the document was > evaluated against the requirements in those specs > and that it passed with flying colors. >=20 > * Section 6 refers to "PT-TLS Auth Types". These > aren't mentioned anywhere else in the spec so > I think this mention should be deleted. Also, > the last paragraph in section 6.1 says "the > following three sections provide guidance to > the IANA" but there are only two following > sections in the IANA Considerations. I think > that should say "two sections". >=20 > * The "Invalid Parameter error code" is referred > to widely but not listed in section 3.9 or > section 6.3. Probably it should be added. >=20 > * The "Authentication Needed" error code is no > longer needed, I think. In fact, it's not > referred to anywhere, although I think that > the "Authentication Required" error code that's > mentioned at the end of section 3.8.3 is it. > But we no longer need it because section 3.8.3 > now says "the NEA Client MUST NOT transition > to the PT-TLS Data Transport phase until it > receives" a SASL Mechanisms TLV with no > mechanisms. So there's no way that a NEA Client > could send a NEA assessment message before the > completion of the client authentication. >=20 > * Error code 5 has a name of "Invalid Message" > in section 3.9 and many other places but it's > named "Invalid Message Error" in section 6.3. > I think that "Invalid Message" is a better > name and it's certainly more widely used so > let's just fix section 6.3. >=20 > * Section 6.3 talks about an "Error Information" > field that's not mentioned anywhere else. > I think we should just delete that. >=20 > Could the document editors please review this list? > If you agree these are minor errors, please fix them. > I want the document that we send to the IESG to be of the highest > quality. >=20 > Thanks, >=20 > Steve >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From internet-drafts@ietf.org Wed May 9 11:47:02 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B5B11E80AB; Wed, 9 May 2012 11:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, 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 n3h32HohH55x; Wed, 9 May 2012 11:47:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3821E21F8551; Wed, 9 May 2012 11:47:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120509184702.28164.2611.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2012 11:47:02 -0700 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-tls-04.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 18:47:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Endpoint Assessment Working G= roup of the IETF. Title : PT-TLS: A TCP-based Posture Transport (PT) Protocol Author(s) : Paul Sangster Nancy Cam-Winget Joseph Salowey Filename : draft-ietf-nea-pt-tls-04.txt Pages : 43 Date : 2012-05-09 This document specifies PT-TLS, a TCP-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-04.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ From shanna@juniper.net Thu May 10 22:11:06 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0C721F8608; Thu, 10 May 2012 22:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVlshszhPE9a; Thu, 10 May 2012 22:11:05 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id E9E6121F8604; Thu, 10 May 2012 22:10:58 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKT6yfYvJ31SPKT8x64iXmTKZkFqnsBheL@postini.com; Thu, 10 May 2012 22:11:02 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 10 May 2012 22:06:42 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 11 May 2012 01:06:41 -0400 From: Stephen Hanna To: Stephen Farrell , "iesg-secretary@ietf.org" Date: Fri, 11 May 2012 01:06:37 -0400 Thread-Topic: PT-TLS Ready for IESG Review Thread-Index: Ac0vM9gVPI4PwDlbQWGRf4n7+SIs/g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_AC6674AB7BC78549BB231821ABF7A9AEB82F583DAAEMBX01WFjnprn_" MIME-Version: 1.0 Cc: "nea@ietf.org" Subject: [Nea] PT-TLS Ready for IESG Review 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, 11 May 2012 05:11:06 -0000 --_002_AC6674AB7BC78549BB231821ABF7A9AEB82F583DAAEMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen, I'm pleased to say that PT-TLS (draft-ietf-nea-pt-tls-04.txt) is ready for IESG evaluation. The NEA WG has reached consensus on this document and now it's ready to go off and begin the broader review and approval process, eventually to become a Standards Track RFC. I will be the Document Shepherd for this document. I have attached a copy of the Document Shepherd Write-Up for it. I look forward to working with you and with the document editors as this document proceeds through the review and approval process. With the cooperation and assistance of the IETF community, I'm sure this will be a big success. Thanks, Steve --_002_AC6674AB7BC78549BB231821ABF7A9AEB82F583DAAEMBX01WFjnprn_ Content-Type: text/plain; name="pt-tls-document-shepherd.txt" Content-Description: pt-tls-document-shepherd.txt Content-Disposition: attachment; filename="pt-tls-document-shepherd.txt"; size=8685; creation-date="Fri, 11 May 2012 05:06:11 GMT"; modification-date="Fri, 11 May 2012 05:06:11 GMT" Content-Transfer-Encoding: base64 KDEpIFdoYXQgdHlwZSBvZiBSRkMgaXMgYmVpbmcgcmVxdWVzdGVkIChCQ1AsIFByb3Bvc2VkIFN0 YW5kYXJkLApJbnRlcm5ldCBTdGFuZGFyZCwgSW5mb3JtYXRpb25hbCwgRXhwZXJpbWVudGFsLCBv ciBIaXN0b3JpYyk/ICBXaHkKaXMgdGhpcyB0aGUgcHJvcGVyIHR5cGUgb2YgUkZDPyAgSXMgdGhp cyB0eXBlIG9mIFJGQyBpbmRpY2F0ZWQgaW4gdGhlCnRpdGxlIHBhZ2UgaGVhZGVyPwoKUHJvcG9z ZWQgU3RhbmRhcmQgaXMgcmVxdWVzdGVkIGFuZCBpbmRpY2F0ZWQgaW4gdGhlIGhlYWRlci4KClBU LVRMUyBpcyBhIHByb3RvY29sIHRoYXQgcGVybWl0cyBORUEgaGFuZHNoYWtlcyBvdmVyIFRMUy4K VGhpcyBpcyBhIGNvbW1vbiBhbmQgd2VsbC1lc3RhYmxpc2hlZCB0ZWNobmlxdWUgdGhhdCBoYXMg YmVlbgp3aWRlbHkgaW1wbGVtZW50ZWQgaW4gdGhvdXNhbmRzIG9mIG9yZ2FuaXphdGlvbnMgdXNp bmcgZWFybGllcgpwcm90b2NvbHMuIFRoZSBkZXNpcmUgaGVyZSBpcyB0byBoYXZlIGEgc3RhbmRh cmQgd2F5IHRvIGFjaGlldmUKdGhpcyBnb2FsIHNvIHRoYXQgdmVuZG9yIGludGVyb3BlcmFiaWxp dHkgY2FuIGJlIGFjaGlldmVkLiBUaGUKUFQtVExTIHNwZWNpZmljYXRpb24gaGFzIGJlZW4gd2lk ZWx5IHJldmlld2VkIGluIHRoZSBORUEgV0cgYW5kCmlzIGJhc2VkIG9uIGJyb2FkIGltcGxlbWVu dGF0aW9uIGV4cGVyaWVuY2Ugd2l0aCBlYXJsaWVyIHByb3RvY29scy4KCigyKSBUaGUgSUVTRyBh cHByb3ZhbCBhbm5vdW5jZW1lbnQgaW5jbHVkZXMgYSBEb2N1bWVudCBBbm5vdW5jZW1lbnQKV3Jp dGUtVXAuIFBsZWFzZSBwcm92aWRlIHN1Y2ggYSBEb2N1bWVudCBBbm5vdW5jZW1lbnQgV3JpdGUt VXAuIFJlY2VudApleGFtcGxlcyBjYW4gYmUgZm91bmQgaW4gdGhlICJBY3Rpb24iIGFubm91bmNl bWVudHMgZm9yIGFwcHJvdmVkCmRvY3VtZW50cy4gVGhlIGFwcHJvdmFsIGFubm91bmNlbWVudCBj b250YWlucyB0aGUgZm9sbG93aW5nIHNlY3Rpb25zOgoKVGVjaG5pY2FsIFN1bW1hcnkKCiAgUFQt VExTIGlzIGEgcHJvdG9jb2wgdGhhdCBjYXJyaWVzIE5FQSBtZXNzYWdlcyBvdmVyIFRMUy4KICBC eSBzdXBwb3J0aW5nIGEgVExTIHRyYW5zcG9ydCwgUFQtVExTIHBlcm1pdHMgZWFzeSBhbmQKICBl ZmZpY2llbnQgYW5kIG1vbml0b3Jpbmcgb2YgZW5kcG9pbnQgcG9zdHVyZSBhZnRlciBhbgogIGVu ZHBvaW50IGhhcyBiZWVuIGFzc2lnbmVkIGFuIElQIGFkZHJlc3MuIFRoaXMgY29udHJhc3RzCiAg d2l0aCBQVC1FQVAsIHdoaWNoIGlzIG1vcmUgc3VpdGFibGUgZm9yIHVzZSBiZWZvcmUgYW4KICBl bmRwb2ludCBoYXMgYmVlbiBhc3NpZ25lZCBhbiBJUCBhZGRyZXNzLgoKV29ya2luZyBHcm91cCBT dW1tYXJ5CgogIFBULVRMUyB3YXMgY2FyZWZ1bGx5IHByZXBhcmVkIGFuZCB0aG9yb3VnaGx5IHJl dmlld2VkCiAgd2l0aGluIHRoZSBORUEgV0cgb3ZlciBhIHBlcmlvZCBvZiBtb3JlIHRoYW4gdHdv IHllYXJzLgogIEFmdGVyIGEgY2FsbCBmb3IgcHJvcG9zYWxzIGluIE9jdG9iZXIgMjAwOSwgdHdv IHByb3Bvc2FscwogIGZvciBhIFRMUy1iYXNlZCB0cmFuc3BvcnQgd2VyZSBzdWJtaXR0ZWQgdG8g dGhlIE5FQSBXRy4KICBUaGUgdHdvIHdlcmUgbWVyZ2VkLCB0YWtpbmcgdGhlIGJlc3QgZmVhdHVy ZXMgb2YgZWFjaAogIGFuZCByZW1vdmluZyB1bm5lZWRlZCBmZWF0dXJlcyBhbmQgZWxlbWVudHMu IFRoZSByZXN1bHRpbmcKICBwcm90b2NvbCByZWNlaXZlZCBhIGNhcmVmdWwgcmV2aWV3IGluIHRo ZSBORUEgV0cgaW5jbHVkaW5nCiAgdHdvIFdHTENzIHdpdGggY29tbWVudHMgZnJvbSBtb3JlIHRo YW4gZml2ZSBwZW9wbGUsIHNvbWUKICBmcm9tIGluZHVzdHJ5IGFuZCBzb21lIGZyb20gYWNhZGVt aWEuIFRoZXJlIHdhcyBjbGVhciBXRwogIGNvbnNlbnN1cyBpbiBmYXZvciBvZiB0aGUgcmVzdWx0 aW5nIGRvY3VtZW50IHdpdGggbm8gY2FzZXMKICBvZiBzdWJzdGFudGlhbCBkaXNhZ3JlZW1lbnQu CgpEb2N1bWVudCBRdWFsaXR5CgogIFdoaWxlIHRoZXJlIGFyZSBubyBrbm93biBpbXBsZW1lbnRh dGlvbnMgb2YgdGhpcyBleGFjdAogIHByb3RvY29sLCBORUEgV0cgbWVtYmVycyBoYXZlIG1hbnkg eWVhcnMgb2YgaW1wbGVtZW50YXRpb24KICBleHBlcmllbmNlIHdpdGggb3RoZXIgVExTLWJhc2Vk IHBvc3R1cmUgcHJvdG9jb2xzIGFuZCBicm91Z2h0CiAgdGhlaXIgZXhwZXJpZW5jZSB0byBiZWFy IGluIGRlc2lnbmluZyB0aGlzIHByb3RvY29sLgoKUGVyc29ubmVsCgogIFRoZSBEb2N1bWVudCBT aGVwaGVyZCBpcyBTdGV2ZSBIYW5uYS4gVGhlIFJlc3BvbnNpYmxlIEFyZWEKICBEaXJlY3RvciBp cyBTdGVwaGVuIEZhcnJlbGwuCgooMykgQnJpZWZseSBkZXNjcmliZSB0aGUgcmV2aWV3IG9mIHRo aXMgZG9jdW1lbnQgdGhhdCB3YXMgcGVyZm9ybWVkIGJ5CnRoZSBEb2N1bWVudCBTaGVwaGVyZC4g IElmIHRoaXMgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgaXMgbm90IHJlYWR5CmZvciBwdWJsaWNh dGlvbiwgcGxlYXNlIGV4cGxhaW4gd2h5IHRoZSBkb2N1bWVudCBpcyBiZWluZyBmb3J3YXJkZWQg dG8KdGhlIElFU0cuCgpUaGUgRG9jdW1lbnQgU2hlcGhlcmQgaGFzIGNhcmVmdWxseSByZXZpZXdl ZCB0aGlzIGRvY3VtZW50CmFuZCBiZWxpZXZlcyB0aGF0IGl0IGlzIHJlYWR5IGZvciBwdWJsaWNh dGlvbi4KCig0KSBEb2VzIHRoZSBkb2N1bWVudCBTaGVwaGVyZCBoYXZlIGFueSBjb25jZXJucyBh Ym91dCB0aGUgZGVwdGggb3IKYnJlYWR0aCBvZiB0aGUgcmV2aWV3cyB0aGF0IGhhdmUgYmVlbiBw ZXJmb3JtZWQ/ICAKCk5vIGNvbmNlcm5zLiBUaGUgZG9jdW1lbnQgaGFzIGJlZW4gY2FyZWZ1bGx5 IGFuZCB0aG9yb3VnaGx5CnJldmlld2VkIGJ5IG1hbnkgTkVBIFdHIG1lbWJlcnMuCgooNSkgRG8g cG9ydGlvbnMgb2YgdGhlIGRvY3VtZW50IG5lZWQgcmV2aWV3IGZyb20gYSBwYXJ0aWN1bGFyIG9y IGZyb20KYnJvYWRlciBwZXJzcGVjdGl2ZSwgZS5nLiwgc2VjdXJpdHksIG9wZXJhdGlvbmFsIGNv bXBsZXhpdHksIEFBQSwgRE5TLApESENQLCBYTUwsIG9yIGludGVybmF0aW9uYWxpemF0aW9uPyBJ ZiBzbywgZGVzY3JpYmUgdGhlIHJldmlldyB0aGF0CnRvb2sgcGxhY2UuCgpCcm9hZGVyIHJldmll dyBpcyBhbHdheXMgd2VsY29tZSBidXQgbm8gcGFydGljdWxhciB0eXBlIG9mCmV4cGVydCByZXZp ZXcgaXMga25vd24gdG8gYmUgbmVlZGVkLgoKKDYpIERlc2NyaWJlIGFueSBzcGVjaWZpYyBjb25j ZXJucyBvciBpc3N1ZXMgdGhhdCB0aGUgRG9jdW1lbnQgU2hlcGhlcmQKaGFzIHdpdGggdGhpcyBk b2N1bWVudCB0aGF0IHRoZSBSZXNwb25zaWJsZSBBcmVhIERpcmVjdG9yIGFuZC9vciB0aGUKSUVT RyBzaG91bGQgYmUgYXdhcmUgb2Y/IEZvciBleGFtcGxlLCBwZXJoYXBzIGhlIG9yIHNoZSBpcyB1 bmNvbWZvcnRhYmxlCndpdGggY2VydGFpbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yIGhhcyBj b25jZXJucyB3aGV0aGVyIHRoZXJlIHJlYWxseQppcyBhIG5lZWQgZm9yIGl0LiBJbiBhbnkgZXZl bnQsIGlmIHRoZSBXRyBoYXMgZGlzY3Vzc2VkIHRob3NlIGlzc3VlcyBhbmQKaGFzIGluZGljYXRl ZCB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRo b3NlCmNvbmNlcm5zIGhlcmUuCgpObyBjb25jZXJucy4gVGhlcmUncyBjbGVhcmx5IGEgbmVlZCBm b3IgdGhpcyBkb2N1bWVudCBhcwppdCBwcm92aWRlcyBhIHN0YW5kYXJkIHdheSB0byBwZXJmb3Jt IGEgY29tbW9uIG9wZXJhdGlvbjoKY2FycnlpbmcgZW5kcG9pbnQgcG9zdHVyZSBpbmZvcm1hdGlv biBvdmVyIFRMUy4gQW5kIHRoaXMKcHJvdG9jb2wgaGFzIGJlZW4gY2FyZWZ1bGx5IGRldmVsb3Bl ZCB3aXRoaW4gdGhlIE5FQSBXRwphbmQgYWNoaWV2ZWQgY29uc2Vuc3VzIHRoZXJlLgoKKDcpIEhh cyBlYWNoIGF1dGhvciBjb25maXJtZWQgdGhhdCBhbnkgYW5kIGFsbCBhcHByb3ByaWF0ZSBJUFIK ZGlzY2xvc3VyZXMgcmVxdWlyZWQgZm9yIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUgcHJvdmlz aW9ucyBvZiBCQ1AgNzgKYW5kIEJDUCA3OSBoYXZlIGFscmVhZHkgYmVlbiBmaWxlZC4gSWYgbm90 LCBleHBsYWluIHdoeS4KClllcy4KCig4KSBIYXMgYW4gSVBSIGRpc2Nsb3N1cmUgYmVlbiBmaWxl ZCB0aGF0IHJlZmVyZW5jZXMgdGhpcyBkb2N1bWVudD8KSWYgc28sIHN1bW1hcml6ZSBhbnkgV0cg ZGlzY3Vzc2lvbiBhbmQgY29uY2x1c2lvbiByZWdhcmRpbmcgdGhlIElQUgpkaXNjbG9zdXJlcy4K Ck5vLgoKKDkpIEhvdyBzb2xpZCBpcyB0aGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3Vt ZW50PyBEb2VzIGl0IApyZXByZXNlbnQgdGhlIHN0cm9uZyBjb25jdXJyZW5jZSBvZiBhIGZldyBp bmRpdmlkdWFscywgd2l0aCBvdGhlcnMKYmVpbmcgc2lsZW50LCBvciBkb2VzIHRoZSBXRyBhcyBh IHdob2xlIHVuZGVyc3RhbmQgYW5kIGFncmVlIHdpdGggaXQ/ICAgCgpUaGVyZSBpcyBzdHJvbmcg Y29uc2Vuc3VzIGZvciB0aGlzIGRvY3VtZW50IHdpdGhpbgp0aGUgTkVBIFdHLiBUd28gV0dMQ3Mg YW5kIHllYXJzIG9mIGRpc2N1c3Npb24gb2YKdGhlIGRvY3VtZW50IHNob3cgdW5hbmltb3VzIHN1 cHBvcnQgYWNyb3NzIGEgbGFyZ2UKbnVtYmVyIG9mIFdHIHBhcnRpY2lwYW50cy4KCigxMCkgSGFz IGFueW9uZSB0aHJlYXRlbmVkIGFuIGFwcGVhbCBvciBvdGhlcndpc2UgaW5kaWNhdGVkIGV4dHJl bWUgCmRpc2NvbnRlbnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRoZSBhcmVhcyBvZiBjb25m bGljdCBpbiBzZXBhcmF0ZQplbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9uc2libGUgQXJlYSBE aXJlY3Rvci4gKEl0IHNob3VsZCBiZSBpbiBhCnNlcGFyYXRlIGVtYWlsIGJlY2F1c2UgdGhpcyBx dWVzdGlvbm5haXJlIGlzIHB1YmxpY2x5IGF2YWlsYWJsZS4pIAoKTm8uCgooMTEpIElkZW50aWZ5 IGFueSBJRCBuaXRzIHRoZSBEb2N1bWVudCBTaGVwaGVyZCBoYXMgZm91bmQgaW4gdGhpcwpkb2N1 bWVudC4gKFNlZSBodHRwOi8vd3d3LmlldGYub3JnL3Rvb2xzL2lkbml0cy8gYW5kIHRoZSBJbnRl cm5ldC1EcmFmdHMKQ2hlY2tsaXN0KS4gQm9pbGVycGxhdGUgY2hlY2tzIGFyZSBub3QgZW5vdWdo OyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlCnRob3JvdWdoLgoKICAqKiBPYnNvbGV0ZSBub3JtYXRp dmUgcmVmZXJlbmNlOiBSRkMgNDM0NiAoT2Jzb2xldGVkIGJ5IFJGQyA1MjQ2KQoKUFQtVExTIHNh eXM6CgogICBJbXBsZW1lbnRhdGlvbnMgb2YgUFQtVExTIE1VU1Qgc3VwcG9ydCB1c2Ugb2YgVExT IDEuMSBbUkZDNDM0Nl0gYW5kCiAgIFNIT1VMRCBhbHNvIGluY2x1ZGUgc3VwcG9ydCBmb3IgVExT IDEuMiBbUkZDNTI0Nl0uCgpXZSBoYXZlIGJlZW4gYXNzdXJlZCB0aGF0IHRoaXMgaXMgcGVybWl0 dGVkIHNpbmNlIG1vc3QKVExTIGltcGxlbWVudGF0aW9ucyB0b2RheSBkbyBub3Qgc3VwcG9ydCBU TFMgMS4yLgoKICAtLSBObyBpbmZvcm1hdGlvbiBmb3VuZCBmb3IgZHJhZnQtaWV0Zi1uZWEtcHQt ZWFwIC0gaXMgdGhlIG5hbWUgY29ycmVjdD8KClBULVRMUyBpbmNsdWRlcyBhIHJlZmVyZW5jZSB0 byBkcmFmdC1pZXRmLW5lYS1wdC1lYXAtMDEudHh0LgpJIHRoaW5rIHRoYXQgaWRuaXRzIGlzIGNv bXBsYWluaW5nIGJlY2F1c2UgdGhlIGRyYWZ0IG5hbWUKaXMgc3BsaXQgYWNyb3NzIHR3byBsaW5l cy4KCigxMikgRGVzY3JpYmUgaG93IHRoZSBkb2N1bWVudCBtZWV0cyBhbnkgcmVxdWlyZWQgZm9y bWFsIHJldmlldwpjcml0ZXJpYSwgc3VjaCBhcyB0aGUgTUlCIERvY3RvciwgbWVkaWEgdHlwZSwg YW5kIFVSSSB0eXBlIHJldmlld3MuCgpOb3QgYXBwbGljYWJsZS4KCigxMykgSGF2ZSBhbGwgcmVm ZXJlbmNlcyB3aXRoaW4gdGhpcyBkb2N1bWVudCBiZWVuIGlkZW50aWZpZWQgYXMKZWl0aGVyIG5v cm1hdGl2ZSBvciBpbmZvcm1hdGl2ZT8KClllcy4KCigxNCkgQXJlIHRoZXJlIG5vcm1hdGl2ZSBy ZWZlcmVuY2VzIHRvIGRvY3VtZW50cyB0aGF0IGFyZSBub3QgcmVhZHkgZm9yCmFkdmFuY2VtZW50 IG9yIGFyZSBvdGhlcndpc2UgaW4gYW4gdW5jbGVhciBzdGF0ZT8gSWYgc3VjaCBub3JtYXRpdmUK cmVmZXJlbmNlcyBleGlzdCwgd2hhdCBpcyB0aGUgcGxhbiBmb3IgdGhlaXIgY29tcGxldGlvbj8K Ck5vIHN1Y2ggcmVmZXJlbmNlcyBleGlzdC4gQWxsIG5vcm1hdGl2ZSByZWZlcmVuY2VzIGFyZSB0 byBCQ1BzCm9yIFN0YW5kYXJkcyBUcmFjayBSRkNzLgoKKDE1KSBBcmUgdGhlcmUgZG93bndhcmQg bm9ybWF0aXZlIHJlZmVyZW5jZXMgcmVmZXJlbmNlcyAoc2VlIFJGQyAzOTY3KT8KSWYgc28sIGxp c3QgdGhlc2UgZG93bndhcmQgcmVmZXJlbmNlcyB0byBzdXBwb3J0IHRoZSBBcmVhIERpcmVjdG9y IGluIHRoZQpMYXN0IENhbGwgcHJvY2VkdXJlLiAKCk5vLiBBbGwgbm9ybWF0aXZlIHJlZmVyZW5j ZXMgYXJlIHRvIEJDUHMgb3IgU3RhbmRhcmRzIFRyYWNrIFJGQ3MuCgooMTYpIFdpbGwgcHVibGlj YXRpb24gb2YgdGhpcyBkb2N1bWVudCBjaGFuZ2UgdGhlIHN0YXR1cyBvZiBhbnkKZXhpc3Rpbmcg UkZDcz8gQXJlIHRob3NlIFJGQ3MgbGlzdGVkIG9uIHRoZSB0aXRsZSBwYWdlIGhlYWRlciwgbGlz dGVkCmluIHRoZSBhYnN0cmFjdCwgYW5kIGRpc2N1c3NlZCBpbiB0aGUgaW50cm9kdWN0aW9uPyBJ ZiB0aGUgUkZDcyBhcmUgbm90Cmxpc3RlZCBpbiB0aGUgQWJzdHJhY3QgYW5kIEludHJvZHVjdGlv biwgZXhwbGFpbiB3aHksIGFuZCBwb2ludCB0byB0aGUKcGFydCBvZiB0aGUgZG9jdW1lbnQgd2hl cmUgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGlzIGRvY3VtZW50IHRvIHRoZQpvdGhlciBSRkNzIGlz IGRpc2N1c3NlZC4gSWYgdGhpcyBpbmZvcm1hdGlvbiBpcyBub3QgaW4gdGhlIGRvY3VtZW50LApl eHBsYWluIHdoeSB0aGUgV0cgY29uc2lkZXJzIGl0IHVubmVjZXNzYXJ5LgoKTm8sIHRoaXMgZG9j dW1lbnQgZG9lcyBub3QgY2hhbmdlIHRoZSBzdGF0dXMgb2YgYW55CmV4aXN0aW5nIFJGQ3MuCgoo MTcpIERlc2NyaWJlIHRoZSBEb2N1bWVudCBTaGVwaGVyZCdzIHJldmlldyBvZiB0aGUgSUFOQSBj b25zaWRlcmF0aW9ucwpzZWN0aW9uLCBlc3BlY2lhbGx5IHdpdGggcmVnYXJkIHRvIGl0cyBjb25z aXN0ZW5jeSB3aXRoIHRoZSBib2R5IG9mIHRoZQpkb2N1bWVudC4gQ29uZmlybSB0aGF0IGFsbCBw cm90b2NvbCBleHRlbnNpb25zIHRoYXQgdGhlIGRvY3VtZW50IG1ha2VzCmFyZSBhc3NvY2lhdGVk IHdpdGggdGhlIGFwcHJvcHJpYXRlIHJlc2VydmF0aW9ucyBpbiBJQU5BIHJlZ2lzdHJpZXMuCkNv bmZpcm0gdGhhdCBhbnkgcmVmZXJlbmNlZCBJQU5BIHJlZ2lzdHJpZXMgaGF2ZSBiZWVuIGNsZWFy bHkKaWRlbnRpZmllZC4gQ29uZmlybSB0aGF0IG5ld2x5IGNyZWF0ZWQgSUFOQSByZWdpc3RyaWVz IGluY2x1ZGUgYQpkZXRhaWxlZCBzcGVjaWZpY2F0aW9uIG9mIHRoZSBpbml0aWFsIGNvbnRlbnRz IGZvciB0aGUgcmVnaXN0cnksIHRoYXQKYWxsb2NhdGlvbnMgcHJvY2VkdXJlcyBmb3IgZnV0dXJl IHJlZ2lzdHJhdGlvbnMgYXJlIGRlZmluZWQsIGFuZCBhCnJlYXNvbmFibGUgbmFtZSBmb3IgdGhl IG5ldyByZWdpc3RyeSBoYXMgYmVlbiBzdWdnZXN0ZWQgKHNlZSBSRkMgNTIyNikuCgpJIGhhdmUg cmV2aWV3ZWQgdGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBmb3IgYWxsIG9mIHRoZXNl Cmlzc3VlcyBhbmQgY2FuIGNvbmZpcm0gdGhhdCBpdCBjb21wbGllcyBhbmQgaXMgY2xlYXJseSB3 cml0dGVuLgoKKDE4KSBMaXN0IGFueSBuZXcgSUFOQSByZWdpc3RyaWVzIHRoYXQgcmVxdWlyZSBF eHBlcnQgUmV2aWV3IGZvciBmdXR1cmUKYWxsb2NhdGlvbnMuIFByb3ZpZGUgYW55IHB1YmxpYyBn dWlkYW5jZSB0aGF0IHRoZSBJRVNHIHdvdWxkIGZpbmQKdXNlZnVsIGluIHNlbGVjdGluZyB0aGUg SUFOQSBFeHBlcnRzIGZvciB0aGVzZSBuZXcgcmVnaXN0cmllcy4KClRoaXMgZG9jdW1lbnQgZGVm aW5lcyB0d28gbmV3IElBTkEgcmVnaXN0cmllczogUFQtVExTIE1lc3NhZ2UgVHlwZXMKYW5kIFBU LVRMUyBFcnJvciBDb2Rlcy4gQm90aCBvZiB0aGVtIHJlcXVpcmUgRXhwZXJ0IFJldmlldyB3aXRo ClNwZWNpZmljYXRpb24gUmVxdWlyZWQuIEluIHNlbGVjdGluZyB0aGUgZXhwZXJ0cyBmb3IgdGhl c2UgcmVnaXN0cmllcywKdGhlIElFU0cgc2hvdWxkIGxvb2sgZm9yIHBlb3BsZSB3aXRoIGdvb2Qg anVkZ21lbnQgYW5kIElFVEYgZXhwZXJpZW5jZS4KUGVvcGxlIHdpdGggZXhwZXJpZW5jZSB3aXRo IFBULVRMUyBhbmQvb3Igb3RoZXIgTkVBIHByb3RvY29scyBzaG91bGQKYmUgcHJlZmVycmVkLiBJ ZiBzdWNoIHBlb3BsZSBhcmUgbm90IGF2YWlsYWJsZSwgcGVvcGxlIHdpdGggc2VjdXJpdHkKcHJv dG9jb2wgZXhwZXJ0aXNlIHNob3VsZCBiZSBwcmVmZXJyZWQuCgooMTkpIERlc2NyaWJlIHJldmll d3MgYW5kIGF1dG9tYXRlZCBjaGVja3MgcGVyZm9ybWVkIGJ5IHRoZSBEb2N1bWVudApTaGVwaGVy ZCB0byB2YWxpZGF0ZSBzZWN0aW9ucyBvZiB0aGUgZG9jdW1lbnQgd3JpdHRlbiBpbiBhIGZvcm1h bApsYW5ndWFnZSwgc3VjaCBhcyBYTUwgY29kZSwgQk5GIHJ1bGVzLCBNSUIgZGVmaW5pdGlvbnMs IGV0Yy4KCk5vdCBhcHBsaWNhYmxlLiBOb25lIG9mIHRoaXMgZG9jdW1lbnQgaXMgd3JpdHRlbiBp biBhIGZvcm1hbCBsYW5ndWFnZS4K --_002_AC6674AB7BC78549BB231821ABF7A9AEB82F583DAAEMBX01WFjnprn_-- From internet-drafts@ietf.org Tue May 15 08:36:14 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4F421F88F4; Tue, 15 May 2012 08:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 XBqf5DsrDRT0; Tue, 15 May 2012 08:36:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A59F21F880B; Tue, 15 May 2012 08:36:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120515153614.23260.30775.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 08:36:14 -0700 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-eap-02.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 15:36:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Endpoint Assessment Working G= roup of the IETF. Title : PT-EAP: Posture Transport (PT) Protocol For EAP Tunnel M= ethods Author(s) : Nancy Cam-Winget Paul Sangster Filename : draft-ietf-nea-pt-eap-02.txt Pages : 20 Date : 2012-05-15 This document specifies PT-EAP, an EAP based Posture Transport (PT) protocol designed to be used only inside a TLS protected tunnel method. The document also describes the intended applicability of PT-EAP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-eap-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-nea-pt-eap-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-nea-pt-eap/ From stephen.farrell@cs.tcd.ie Thu May 17 05:08:26 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7505121F8582 for ; Thu, 17 May 2012 05:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, 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 mXuCRXZT4zWE for ; Thu, 17 May 2012 05:08:24 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7B021F8542 for ; Thu, 17 May 2012 05:08:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 69D85171591; Thu, 17 May 2012 13:08:23 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1337256501; bh=jMCYkGKo48OwNh H6lk78/ZGmNKMB/mj2zyKZSdaFnRI=; b=o9BaJdxL0rDqfPDoBirDrJM/5lmu8F Ykr62Lz544bAPGi+WBuwSmxOnds9BnjcvTPnh4GYFE0XgW4psOhOAeDvh6xG4DLb vhAdf0UZxaz5ItioKIjdDjX3HkNkZVNoXQ6dR7NKI5RQCCvKjURVeLGfPsR9ryFz ZLrj/QNZcRzEXQ8Ja//Z5DUWSozNMDCWWmv+v97vvCknHaG/o8xLp+ZKZ5ptS3OY jRMj6+72K43nwZAjfZarlhJWdCxZvFrnEN78JhslALRKyUfErMEU/4TIMTEbb2GJ OvSqL9+G0vzg5qnQA2peNJ8+Fc5poOGM4TJ1eTAXuQhj0dqjSOSDtZKQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id zxs2UBFmhbb7; Thu, 17 May 2012 13:08:21 +0100 (IST) Received: from [IPv6:2001:770:10:203:69d6:549f:24bf:4a87] (unknown [IPv6:2001:770:10:203:69d6:549f:24bf:4a87]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 0801317158F; Thu, 17 May 2012 13:08:20 +0100 (IST) Message-ID: <4FB4EA34.2020104@cs.tcd.ie> Date: Thu, 17 May 2012 13:08:20 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Stephen Hanna References: In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nea@ietf.org" Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 12:08:26 -0000 Hi Steve, My AD review of this is below. I think question 1 is the main one where I have a concern really, the others are mostly not-quite-nits or things where I'm just asking, or where there'd be an easy fix if a change is needed. I dunno if this will require a revised I-D or not. I suspect it will, but will wait for your/the WG's response before putting it in that state. Please do argue about that if, having seen this review, you think this doesn't require another rev. (And if some of my questions are just dumb, then do say, I'm quite used to that:-) Cheers, S. Questions: (1) 3.1.1, This says in one place "the NEA Client is effectively acting as a TLS server" which I thought was going to be more strongly deprecated or entirely removed? While you do recommend (RECOMMEND is good 2119 language btw) not doing that, it won't work in many cases, so is it really worth keeping at all? How about just leaving in the first and last paragraphs of 3.1.1? (Would need some more edits to fix up, but all of those would simplify the document overall.) (2) 3.3, last sentence: this says "an attack" - is this normative instruction meant to apply only for detected Asokan attacks, or does it also apply for any other attack at all, or for some others? For example, what if the TLS handshake terminates fails for some reason not specifically stated in this document? What if some new unexpected attack on NEA is discovered - would this MUST apply to that? I guess choices are to s/an attack/this attack/ if you just want this to cover the Asokan attack, or if a more general statement is desirable then maybe adding something somewhere else would be right. (3) 3.4.2: How do I know that the "TLS Setup" phase has completed and how do I enforce the requirement that TLS re-negotiation MUST NOT happen after that? The former seems unclear unless it means "after the Finished exchanges" in which case maybe say so. The latter seems tricky - will current TLS implementations allow you to enforce that? (4) 3.4.1.1: You do validation according to 5280 which is fine. But in 5280, revocation checking is optional. Do you need to check revocation here? If you do, then do you need to say that the NEA client might need to contact an OCSP responder, or is some further profiling of how TLS and 5280 are used needed? (e.g. OCSP stapling?) There are a bunch of reasonable answers possible and I'm fine with any of 'em (particularly whatever folks will implement:-) but I suspect you may need to say a bit more here. (5) 3.4.2.3 - The last sentence is a bit confusing - what should happen if a "NEA protocol" may not be able to make use of full-duplex? (And maybe s/protocol/implementation/?) What do you do if you're one of those or talking to one of those? (6) 3.5: I don't think that enterprise numbers [1] are restricted to 24 bits - those are OID arcs which are in theory unlimited length. What happens if one is larger than 24bits? Reserving a number from that registry also probably needs an IANA action, and who knows that might conflict with something else. I know you set this to zero but I'm guessing vendors will use this as well or its used elsewhere by NEA so I do wonder. This also affects 3.9. (Nits on this as well: That might also be better stated as "Implementations of this specification MUST..." just for clarity. And it'd be good to put in a link or reference to the IANA registry somewhere - not everyone knows what that registry is I guess. Also, referring to 0 as an IETF SMI Private Entreprise Number might raise a hackle, since that's reserved in the IANA registry. Having said all that, if you got this past in other NEA RFCs (didn't check) then doing the same thing here is probably ok.) [1] http://www.iana.org/assignments/enterprise-numbers (7) 3.5, Message Type. I don't understand what "MUST interoperate with other parties despite any differences" means here and suspect that that 2119 MUST isn't doable. (8) 3.5, 6.2 Any "reserved" values should really be mentioned in the IANA considerations section so IANA don't go and give them out, I mean the 0xffff... ones. "9+" is also a bit odd in 6.2. You might want to change that to specify the exact range "available for allocation by DE" (or whatever is the right term) different from the "reserved" value(s) there. (9) 3.6, is it really ok for the "TLS session initiator" to always be the one who proposes the versions in the version request message? You still allow the NEA server to be the TLS session initiator so what'd happen with this then is confusing - the naughty client could get to pick the weakest version of PT-TLS that the server supports? 3.7 also seems to contradict this, saying that the "PT-TLS initiator" sends the version request. Maybe there is some cleaning up needed here? (10) 4.1, are you saying here that if any of these trust relationships do not hold, then PT-TLS ought not be used? If so, then saying that explicitly would be good. For example, it could be that with some implementations, e.g. that use less secure inter-proces communications, a bad process on a client could invalidate some of these assumptions, thus (maybe) making PT-TLS unsafe. (11) section 5: do you mean the NEA client SHOULD (in 2119 terms) provide an indication here? If not, why not? If so, what's the criteria for not providing that? (Perhaps if there is no UI?) Same should/SHOULD question for the last paragraph, i.e. s/should ensure/SHOULD ensure/ and what's the exception? (12) section 6: some of the intro text here is not really for IANA, should it be moved elsewhere? (Mainly the explanation of PEN handling, which might go up into 3.5 perhaps?) (13) section 6.1: you're asking IANA to act as a repository for non-RFC specifications (sort-of), I think that's maybe an innovation (not sure) that should be checked out with IANA, or maybe you've done that or know of a precedent? (14) 6.2 & 6.3 - do you need to tell IANA or the DE that entries with PEN value 0 need to be IETF stream RFCs, or standards-track RFCs, or just RFCs or what? If you want the DE to be able to add PEN=0 entries without an RFC, I think saying that would be best. (15) References: can we not make the reference to 4346 (TLS 1.1) informative and craft language to make that work? E.g. say you SHOULD support TLS1.2 but that in reality a lot of people still don't and are only doing 4346 as of now? I think if you do that you can argue that TLS 1.1 is not a normative reference and that'd be better in future once most everyone has caught up with TLS1.2. Nits: - 1.4: Not sure its right to talk about the future actions of some other organisation in such a definite manner. Might be better to say that "the authors understand that..." or some other weasel words, or even better would be to refer to something the TCG have published if that's possible. - s2, 1st para: maybe s/should use/can use/ just to avoid rfc 2119 confusion. - 2.1, why use the "underlying carrier protocol" when only TCP is covered here? - 2.4, I'm not clear why this section is (still) needed. It tries to say, but I don't get it. Did you once want to control what ciphersuites could be used by TLS as part of NEA? No problem with it staying though. - 3.1.2, last sentence, s/must/MUST/? or s/must/needs to be/? - 3.4.2, s/normally starts/starts/ how else can it work? Also not quite correct to say the connection triggers TLS h/s - the sending/listening processes do that. - 3.4.2.2: The end of this phase is also a little ambiguous. You say we're done when the NEA server has sent an empty list of sasl mechanisms after all NEA client authentications are done. But then you also say that the NEA server can choose to not authenticate the client and move on. But how would the client know that the PT-TLS negotiation phase is over in that case? Ah, 3.8.3 clears this up. Might be worth clarifying that a bit in 3.4.2.2. - 3.5, Message Id. Since receivers have to handle roll over, there doesn't seem to be a need for a MUST start at zero, is there? And maybe you don't even really need the MUST monotonically increasing either? (Aside: I generally prefer if senders can start randomly anyway, just in case there's some message guessing threat - never any harm to make that harder IMO.) - 3.5, message length: your answer here is probably "no," which is fine, but I wondered if there's any useful guidance about over-long messages that could be given? E.g. could a NEA client try send a (number of) 2^31 byte payload(s) to DoS the server in the hope that the server would then fail-open? (I note that the TLS plaintext max is 2^14 bytes in one record, dunno if that might be a factor here or not to be honest.) - 3.6, seems off for a standards track RFC to distinguish between production code and something else, maybe that could be better phrased? - 3.6, PB-TNC batch: total and utter nit:-) The reference to section 4 of the PB-TNC spec is rendered with the wrong URL in the tools.ietf.org version of the draft. (Interpreted as a link to section 4 of this.) I think if you added the RFC number for PB-TNC it might help there. - 3.8, 2nd last para, maybe s/may require/MAY require/ ? - 3.8.5.4, maybe s/may trigger/MAY trigger/ ? - section 6, s/requests the IANA/requests that IANA/? - 6.2, "Once this document becomes an RFC..." probably ought be deleted. Easier if that's a separate paragraph with an instruction to the RFC editor as to what to delete, which is not all of the paragraph in this case I think. From jsalowey@cisco.com Thu May 17 11:51:32 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B32B421F86A6 for ; Thu, 17 May 2012 11:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 CjWwWAg3cQ93 for ; Thu, 17 May 2012 11:51:31 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1C821F86F1 for ; Thu, 17 May 2012 11:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=4842; q=dns/txt; s=iport; t=1337280691; x=1338490291; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tE2bLpkTvTsW+HRToVUMigmDexu+SHh+vYUl4Om2hNo=; b=dnSa79iQkPgY8McK2MobD6xzFhV1tkWcf/jig/mdctpQKg866M6DCTF0 hzGmKJA+Nk5lZo/PC3Jrn52PvcVm6KYWV2UCZ85p7jeMp+dss4gv9ivUa sgKrIed2FkjmA2ZtzHs/No6W4Zv5Gc/Rj+NUTpynbfJZLJGcCbY8iyauJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcFAFdItU+rRDoG/2dsb2JhbABEgx2wLIEHghUBAQEDAQEBAQ8BWwQHBQsLGC4nMAYTIodnBAybeZ9/BIsThHViA4hjjReFdYhigWmDCQ X-IronPort-AV: E=Sophos;i="4.75,611,1330905600"; d="scan'208";a="42643517" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 17 May 2012 18:51:31 +0000 Received: from [10.33.251.111] ([10.33.251.111]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4HIpU8B025575; Thu, 17 May 2012 18:51:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Joe Salowey In-Reply-To: Date: Thu, 17 May 2012 11:51:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <258BE838-59F8-441F-ABE7-172A8F1B03FF@cisco.com> References: To: Clifford Kahn X-Mailer: Apple Mail (2.1084) Cc: "nea@ietf.org" Subject: Re: [Nea] Review comments on Asokan Attack Analysis X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 18:51:32 -0000 On May 2, 2012, at 12:30 PM, Clifford Kahn wrote: > Hi Joe. >=20 >> Thanks for taking time to review the document and provide good = comments. >=20 > Glad to help. >=20 >> On Apr 28, 2012, at 8:36 PM, Clifford Kahn wrote: >=20 >> =D8 The recommendations for addressing the NEA Asokan Attack are as = follows: >>=20 >> To whom are these recommendations? To implementers, or to writers of = specs? =20 >>=20 >=20 > [Joe] Mostly to writers of specs, but it should also help implementers = understand the motivation behind the specification.=20 >=20 > [Cliff] That makes sense. So the recommendations are for protocols. = The recommendations in most IETF specs are for implementations of = protocols, which is a little bit different. It may help to reword each = recommendation something like: "Protocols should make use of = cryptographic binding ..." >=20 >=20 [Joe] OK, sounds good.=20 >> =D8 1. Make use of cryptographic binding, however binding identities = of the tunnel endpoints in the EMA may be useful. >>=20 >> The "however" is confusing. I think it means that one should make = use of cryptographic binding, and that in addition binding identities of = the tunnel endpoints in the EMA may be useful. Whether I got it right = or not, please consider rephrasing. >=20 > [Joe] Good catch, this should be reworded and the bit about the tunnel = identities should be removed. How about: >=20 > "Make use of cryptographic binding to protect the integrity of the TLS = tunnel. "=20 >=20 > [Cliff] That works for me. >=20 >>=20 >> =D8 2. Use the same mechanism in L2 and L3 PT transports that make = use of TLS (e.g. PT-TLS and PT-EAP). >>=20 >> I take it that "the same mechanism" refers to the two mechanisms in = recommendation 1. But will others take it that way?=20 >>=20 >> Doesn't recommendation 1 entail recommendation 2? Why is 2 here? = Since 2 is here, I take it that 1 must have in mind transports other = than the ones 2 mentions. But 1 doesn't say what transports it has in = mind - or I don't understand. >>=20 >=20 > [Joe] How about: >=20 > "Use the same cryptographic binding mechanism in L2 and L3 TLS-based = PT transports (e.g. PT-TLS and PT-EAP)." >=20 > [Cliff] I don't think that helps me. Sorry to be thick. Doesn't = recommendation 1 cover all transports? Isn't recommendation 2 a = corollary and redundant? =20 >=20 > If recommendation 1 does not cover all transports, I suggest making it = say which transports it covers. If recommendation 1 does cover all = transports and recommendation 2 is a corollary, you might either delete = recommendation 2 or make recommendation 2 begin "In particular": >=20 > "In particular, L2 and L3 TLS-based PT transports ... should use = cryptographic binding ..." =20 >=20 > That would clear up the relationship between recommendations 1 and 2.=20= >=20 [Joe] I like the second suggestion a little better. How about: "2. In particular, L2 and L3 TLS-based PT transports (e.g. PT-TLS and = PT-EAP) should use the same cryptographic binding mechanism" >=20 >> =D8 3. Neither TLS endpoint can be in sole control of the TLS = pre-master secret. This is not strictly necessary when tls-unique = channel binding values are used. >>=20 >> I'm a bit confused by the double negative. The first sentence is a = negative, and the second negates that negative.=20 >>=20 >> I think it means that when TLS-unique channel binding values are = used, it's kind of OK for one TLS endpoint to be in sole control of the = TLS pre-master secret. Whether I got it right or not, please consider = rephrasing. >>=20 >=20 > [Joe] Yes, that is correct. The text is a bit confusing and = unnecessary since we recommend use of TLS unique, I think we should = delete this item. we could add to 4: >=20 > "The preferred approach is to use the tls-unique channel binding data = from RFC 5929 [9]. The tls-unique value will be made available to the = EMA that will use it. This approach can utilize any TLS cipher suite = based on a strong cipher algorithm." >=20 > (perhaps this just opens the can of worms of what a strong cipher = algorithm is.) >=20 > [Cliff] I like the simplification and the clarity. >=20 > If one's cipher suite is not strong enough and an attacker cracks it, = then all bets are off. That's always true. I don't see why a strong = cipher suite is more needed here than it is in other places. If you = agree with that, you might want to delete "based on a strong cipher = algorithm". =20 >=20 [Joe] I agree. =20 > Thanks for considering my comments. > Cliff >=20 >>=20 >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea >=20 From jsalowey@cisco.com Thu May 17 13:08:18 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1C321F8649 for ; Thu, 17 May 2012 13:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuEtVB1lbG+0 for ; Thu, 17 May 2012 13:08:13 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 875AA21F863F for ; Thu, 17 May 2012 13:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=3510; q=dns/txt; s=iport; t=1337285293; x=1338494893; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=VfRzEf73YMzOvasjPzGjYIZtCloOB82ZCUaLqNawmCA=; b=R7OaFJR5nkR5QyNowVRrEfsh0SuZNocr7EROMNEtlnXRAqAKJw9Am0Oa sXm2bhH1RW2Gm5BAe3uaE7DbK9OOvBpQKI+ZE+YVp4yFvliHAEkG2hZJ7 E7wxClQSidF38OGRmMvVYfj0T8JwEaiIKy0cJV9dY5Db5s38/MzP1/nnQ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFABtatU+rRDoH/2dsb2JhbAA7CYMdsC2BB4IVAQEBAwEBAQEPASc0CwULCxguJzAGEyKHZwQMnAqgAYsEEIRZYgOIW4x/gRGEU4hSgWSDCYE2BwI X-IronPort-AV: E=Sophos;i="4.75,611,1330905600"; d="scan'208";a="42656434" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 17 May 2012 20:08:13 +0000 Received: from [10.33.251.111] ([10.33.251.111]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4HK8CoV010833; Thu, 17 May 2012 20:08:12 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4FA3C664.4000208@angry-red-pla.net> Date: Thu, 17 May 2012 13:08:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <05D091D3-7810-4B51-BB09-64D126F99E80@cisco.com> References: <4FA3C664.4000208@angry-red-pla.net> To: Carolin Latze X-Mailer: Apple Mail (2.1084) Cc: nea@ietf.org Subject: Re: [Nea] WGLC on NEA Asokan Attack Analysis X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 20:08:18 -0000 Hi Carolin, PT-TLS and PT-EAP implement mechanism to enforce both cryptographic = binding and identity. They do not implement all the possible mechanisms = for cryptographic binding because that would be a bit redundant. Here = is an attempt at some better text: "The PT-TLS [5] and PT-EAP [6] protocols developed by the NEA working = group include mechanisms that can provide cryptographic binding and = identity binding countermeasures."=20 Cheers, Joe On May 4, 2012, at 5:07 AM, Carolin Latze wrote: > Hi >=20 > I have just one comment. In the introduction it is said that "The NEA = WG has included several of these countermeasures in PT-TLS [5] and = PT-EAP [6]" The first question that came into my mind was "and why not = all of them?" :-) So maybe it would make sense to describe the reasoning = behind the selection of the countermeasures that will be used in PT-TLS = and PT-EAP. >=20 > regards > Carolin >=20 > On 04/27/2012 04:58 PM, Stephen Hanna wrote: >> As previously agreed, the NEA Asokan Attack Analysis >> has been changed into a NEA WG draft. This draft has >> received several years of discussion and review in >> our WG, dating back to its initial publication as >> draft-salowey-nea-asokan-00.txt back in October 2010. >>=20 >> We agreed to make this document a WG draft because >> we found its analysis essential to describing the need >> for TLS channel bindings to prevent Asokan attacks. >> Both PT-TLS and PT-EAP contain informational but >> important references to this document. For those >> documents to be fully understood, it's essential >> for the NEA Asokan Attack Analysis to become an >> informational RFC. >>=20 >> Therefore, I'd like to ask all active NEA WG >> participants to please review the latest draft >> of the NEA Asokan Attack Analysis and to send >> comments, corrections, or questions to the WG >> list. Please complete this Working Group Last >> Call review within two weeks (by 1600 GMT on >> Friday, May 11 - noon EDT or 9 AM PDT). If any >> substantive issues have been raised, we'll get >> those resolved. And if there's WG consensus to >> ask the IESG to advance the document to >> Informational RFC status, we'll do that. >>=20 >> If you don't have any comments on the document >> but you agree that it should advance to >> Informational RFC status, you can just send >> an email in response to this one saying so. >> And if you think that it should not advance, >> please send an email saying that also. These >> emails will be useful in judging WG consensus. >>=20 >> Here's a link to the draft for review: >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-nea-asokan/ >>=20 >> At only eight pages in length (and really only >> four pages of content), I think you will find it >> an easy but interesting read. In any event, you >> should learn something. And something quite >> relevant to NEA. If you've already read the >> document before, a quick skim should help you >> confirm that you're comfortable with the latest >> version (or not). Your brief review and comment >> would be greatly appreciated. >>=20 >> Thanks in advance for your help, >>=20 >> Steve >>=20 >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea >> =20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From Paul_Sangster@symantec.com Thu May 17 14:15:52 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABF0B21F8820 for ; Thu, 17 May 2012 14:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 hQV1DzH0x1YI for ; Thu, 17 May 2012 14:15:51 -0700 (PDT) Received: from ecl1mtaoutpex01.symantec.com (ecl1mtaoutpex01.symantec.com [166.98.1.209]) by ietfa.amsl.com (Postfix) with ESMTP id 1840721F881E for ; Thu, 17 May 2012 14:15:51 -0700 (PDT) X-AuditID: a66201d1-b7fb06d000003ef4-00-4fb56a868f90 Received: from ecl1mtahubpin02.ges.symantec.com (ECL1MTAHUBPIN02.ges.symantec.com [10.48.69.202]) by ecl1mtaoutpex01.symantec.com (Symantec Messaging Gateway) with SMTP id 1B.AA.16116.68A65BF4; Thu, 17 May 2012 21:15:50 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1SV7xM-0008OZ-67; Thu, 17 May 2012 21:09:56 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([169.254.188.134]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([172.24.185.246]) with mapi; Thu, 17 May 2012 14:09:56 -0700 From: Paul Sangster To: Stephen Farrell , Stephen Hanna Date: Thu, 17 May 2012 14:10:30 -0700 Thread-Topic: [Nea] AD review of draft-ietf-nea-pt-tls-04 Thread-Index: Ac00JcplI3cv5ZHDR9SCk1FDpiDZ9AASdwrg Message-ID: <6E79D623502C70419A9EAB18E4D274252B881C825E@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4FB4EA34.2020104@cs.tcd.ie> In-Reply-To: <4FB4EA34.2020104@cs.tcd.ie> 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+NgFlrKIsWRmVeSWpSXmKPExsXCZeB6Srcta6u/wf1+LovPbyssHp87xWwx fe81dgdmj7XdV9k8liz5yeRxvekqewBzFJdNSmpOZllqkb5dAlfG0783WAr+x1Wc653I2MC4 y7uLkZNDQsBEYu2KG+wQtpjEhXvr2boYuTiEBF4ySiz7tQLKec0ocefZPLAqIYHVjBJHXwaC 2GwCBhI7j5wCi4sIhEos3biFEcRmFlCUmN66lAnEZhFQldh+rxWsRljAQuLWgsWMEPWWEkcu fWKBsI0k5k5bClbDKxAl0Xh6BxPEriyJlRcOgNmcApoSPWtXsYHYjECXfj+1hglil7jErSfz mSA+EJBYsuc8M4QtKvHy8T9WiHpRiTvt66Fu05FYsPsTG4StLbFs4WtmiL2CEidnPmGZwCg+ C8nYWUhaZiFpmYWkZQEjyypGmdTkHMPcksT80pKC1AoDQ73iytxEYNQl6yXn525iBEbesiTG izsYLxzWPcQowMGoxMN7PnKrvxBrYhlQ5SFGCQ5mJRHe/epAId6UxMqq1KL8+KLSnNTiQ4zS HCxK4ryL04FSAumJJanZqakFqUUwWSYOTqkGxg1/jcRz2E6ay6ty7jhpGp/+V/QDh/7CIJNf ebILIxxuhv/MzpK+vPD44YJo7XM7XmSlnZi/yqNDx6klbFHyYX/n4Lec3OcOPGX5KNOYXpBr 9GRzhNz19FSBH6dzpsQvKVjxkY/53x3GWcF602b1V0Tu10mx5d3HGPFc0/HRw9P7Ge8+r1re p8RSnJFoqMVcVJwIACa9Boa4AgAA Cc: "nea@ietf.org" Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 21:15:52 -0000 Stephen, Thanks for all the great feedback, I suspect we would need to do a revision= to address everything. Let me respond to question 1 since its mentioned a= s the primary concern. We've discussed the inbound NEA Server initiated as= sessments a few times and hadn't ever planned to remove it since it's such = a useful feature. Clearly its use comes with some risks that deployers nee= d to account for with countermeasures. Having that feature in the specific= ation allows implementers and deployers to use that feature in a standards = based way and an understanding of the risks. Personally, I don't view the have every endpoint nail up the TCP connection= to the NEA Server for re-assessments as a great solution for everyone (e.g= . scaling issues, only usable by AAA server, ...). Allowing customers part= icularly those with internal deployments inside the enterprise edge firewal= ls to have network infrastructure devices beside just the AAA server (e.g. = compliance/conformance, patch management or security management tools) to r= each out to the desktops and perform assessments when network security poli= cies change or as urgent patches are released is a nice feature to allow. Endpoint agents could accept only IPsec or TLS protected connections as a c= ountermeasure against many forms of attack on the exposed ports. Leaving t= he option in allows the deployer to decide what works best with their deplo= yment (scale, product mix, threat model and goals). Paul > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Stephen Farrell > Sent: Thursday, May 17, 2012 5:08 AM > To: Stephen Hanna > Cc: nea@ietf.org > Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 >=20 >=20 > Hi Steve, >=20 > My AD review of this is below. I think question 1 > is the main one where I have a concern really, the > others are mostly not-quite-nits or things where I'm > just asking, or where there'd be an easy fix if > a change is needed. >=20 > I dunno if this will require a revised I-D or not. > I suspect it will, but will wait for your/the WG's > response before putting it in that state. Please > do argue about that if, having seen this review, > you think this doesn't require another rev. >=20 > (And if some of my questions are just dumb, then > do say, I'm quite used to that:-) >=20 > Cheers, > S. >=20 > Questions: >=20 > (1) 3.1.1, This says in one place "the NEA Client is > effectively acting as a TLS server" which I thought was > going to be more strongly deprecated or entirely removed? > While you do recommend (RECOMMEND is good 2119 language > btw) not doing that, it won't work in many cases, so is it > really worth keeping at all? How about just leaving in the > first and last paragraphs of 3.1.1? (Would need some more > edits to fix up, but all of those would simplify the > document overall.) >=20 > (2) 3.3, last sentence: this says "an attack" - is this > normative instruction meant to apply only for detected > Asokan attacks, or does it also apply for any other attack > at all, or for some others? For example, what if the TLS > handshake terminates fails for some reason not specifically > stated in this document? What if some new unexpected attack > on NEA is discovered - would this MUST apply to that? I > guess choices are to s/an attack/this attack/ if you just > want this to cover the Asokan attack, or if a more general > statement is desirable then maybe adding something > somewhere else would be right. >=20 > (3) 3.4.2: How do I know that the "TLS Setup" phase has > completed and how do I enforce the requirement that TLS > re-negotiation MUST NOT happen after that? The former seems > unclear unless it means "after the Finished exchanges" in > which case maybe say so. The latter seems tricky - will > current TLS implementations allow you to enforce that? >=20 > (4) 3.4.1.1: You do validation according to 5280 which is > fine. But in 5280, revocation checking is optional. Do you > need to check revocation here? If you do, then do you need > to say that the NEA client might need to contact an OCSP > responder, or is some further profiling of how TLS and 5280 > are used needed? (e.g. OCSP stapling?) There are a bunch > of reasonable answers possible and I'm fine with any of 'em > (particularly whatever folks will implement:-) but I > suspect you may need to say a bit more here. >=20 > (5) 3.4.2.3 - The last sentence is a bit confusing - what > should happen if a "NEA protocol" may not be able to make > use of full-duplex? (And maybe s/protocol/implementation/?) > What do you do if you're one of those or talking to one of > those? >=20 > (6) 3.5: I don't think that enterprise numbers [1] are > restricted to 24 bits - those are OID arcs which are in > theory unlimited length. What happens if one is larger than > 24bits? Reserving a number from that registry also probably > needs an IANA action, and who knows that might conflict > with something else. I know you set this to zero but I'm > guessing vendors will use this as well or its used > elsewhere by NEA so I do wonder. This also affects 3.9. > (Nits on this as well: That might also be better stated as > "Implementations of this specification MUST..." just for > clarity. And it'd be good to put in a link or reference to > the IANA registry somewhere - not everyone knows what that > registry is I guess. Also, referring to 0 as an IETF SMI > Private Entreprise Number might raise a hackle, since > that's reserved in the IANA registry. Having said all that, > if you got this past in other NEA RFCs (didn't check) then > doing the same thing here is probably ok.) >=20 > [1] http://www.iana.org/assignments/enterprise-numbers >=20 > (7) 3.5, Message Type. I don't understand what "MUST > interoperate with other parties despite any differences" > means here and suspect that that 2119 MUST isn't doable. >=20 > (8) 3.5, 6.2 Any "reserved" values should really be > mentioned in the IANA considerations section so IANA don't > go and give them out, I mean the 0xffff... ones. "9+" is > also a bit odd in 6.2. You might want to change that to > specify the exact range "available for allocation by DE" > (or whatever is the right term) different from the > "reserved" value(s) there. >=20 > (9) 3.6, is it really ok for the "TLS session initiator" to > always be the one who proposes the versions in the version > request message? You still allow the NEA server to be the > TLS session initiator so what'd happen with this then is > confusing - the naughty client could get to pick the > weakest version of PT-TLS that the server supports? 3.7 > also seems to contradict this, saying that the "PT-TLS > initiator" sends the version request. Maybe there is some > cleaning up needed here? >=20 > (10) 4.1, are you saying here that if any of these trust > relationships do not hold, then PT-TLS ought not be used? > If so, then saying that explicitly would be good. For > example, it could be that with some implementations, e.g. > that use less secure inter-proces communications, a bad > process on a client could invalidate some of these > assumptions, thus (maybe) making PT-TLS unsafe. >=20 > (11) section 5: do you mean the NEA client SHOULD (in 2119 > terms) provide an indication here? If not, why not? If so, > what's the criteria for not providing that? (Perhaps if > there is no UI?) Same should/SHOULD question for the last > paragraph, i.e. s/should ensure/SHOULD ensure/ and what's > the exception? >=20 > (12) section 6: some of the intro text here is not really > for IANA, should it be moved elsewhere? (Mainly the > explanation of PEN handling, which might go up into 3.5 > perhaps?) >=20 > (13) section 6.1: you're asking IANA to act as a repository > for non-RFC specifications (sort-of), I think that's maybe > an innovation (not sure) that should be checked out with > IANA, or maybe you've done that or know of a precedent? >=20 > (14) 6.2 & 6.3 - do you need to tell IANA or the DE that > entries with PEN value 0 need to be IETF stream RFCs, > or standards-track RFCs, or just RFCs or what? If you > want the DE to be able to add PEN=3D0 entries without > an RFC, I think saying that would be best. >=20 > (15) References: can we not make the reference to 4346 (TLS > 1.1) informative and craft language to make that work? E.g. > say you SHOULD support TLS1.2 but that in reality a lot of > people still don't and are only doing 4346 as of now? I > think if you do that you can argue that TLS 1.1 is not > a normative reference and that'd be better in future once > most everyone has caught up with TLS1.2. >=20 > Nits: >=20 > - 1.4: Not sure its right to talk about the future actions > of some other organisation in such a definite manner. > Might be better to say that "the authors understand > that..." or some other weasel words, or even better would > be to refer to something the TCG have published if that's > possible. >=20 > - s2, 1st para: maybe s/should use/can use/ just to avoid > rfc 2119 confusion. >=20 > - 2.1, why use the "underlying carrier protocol" when only > TCP is covered here? >=20 > - 2.4, I'm not clear why this section is (still) needed. > It tries to say, but I don't get it. Did you once want to > control what ciphersuites could be used by TLS as part of > NEA? No problem with it staying though. >=20 > - 3.1.2, last sentence, s/must/MUST/? or s/must/needs to > be/? >=20 > - 3.4.2, s/normally starts/starts/ how else can it work? > Also not quite correct to say the connection triggers TLS > h/s - the sending/listening processes do that. >=20 > - 3.4.2.2: The end of this phase is also a little > ambiguous. You say we're done when the NEA server has sent > an empty list of sasl mechanisms after all NEA client > authentications are done. But then you also say that the > NEA server can choose to not authenticate the client and > move on. But how would the client know that the PT-TLS > negotiation phase is over in that case? Ah, 3.8.3 clears > this up. Might be worth clarifying that a bit in 3.4.2.2. >=20 > - 3.5, Message Id. Since receivers have to handle roll > over, there doesn't seem to be a need for a MUST start at > zero, is there? And maybe you don't even really need the > MUST monotonically increasing either? (Aside: I generally > prefer if senders can start randomly anyway, just in case > there's some message guessing threat - never any harm to > make that harder IMO.) >=20 > - 3.5, message length: your answer here is probably "no," > which is fine, but I wondered if there's any useful > guidance about over-long messages that could be given? E.g. > could a NEA client try send a (number of) 2^31 byte > payload(s) to DoS the server in the hope that the server > would then fail-open? (I note that the TLS plaintext max > is 2^14 bytes in one record, dunno if that might be a > factor here or not to be honest.) >=20 > - 3.6, seems off for a standards track RFC to distinguish > between production code and something else, maybe that > could be better phrased? >=20 > - 3.6, PB-TNC batch: total and utter nit:-) The reference > to section 4 of the PB-TNC spec is rendered with the wrong > URL in the tools.ietf.org version of the draft. > (Interpreted as a link to section 4 of this.) I think if > you added the RFC number for PB-TNC it might help there. >=20 > - 3.8, 2nd last para, maybe s/may require/MAY require/ ? >=20 > - 3.8.5.4, maybe s/may trigger/MAY trigger/ ? >=20 > - section 6, s/requests the IANA/requests that IANA/? >=20 > - 6.2, "Once this document becomes an RFC..." probably > ought be deleted. Easier if that's a separate paragraph > with an instruction to the RFC editor as to what to delete, > which is not all of the paragraph in this case I think. >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea From stephen.farrell@cs.tcd.ie Fri May 18 01:02:54 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40FF21F856F for ; Fri, 18 May 2012 01:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.7 X-Spam-Level: X-Spam-Status: No, score=-98.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 h8jTAwF-xj9P for ; Fri, 18 May 2012 01:02:53 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 19C8F21F859E for ; Fri, 18 May 2012 01:02:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 17A801714FE; Fri, 18 May 2012 09:02:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1337328168; bh=d+V7To6TgIlcTn Sz9kadLRhf86l1CQ6W4dTtZFB8giw=; b=G1qdaK/cyezHtmz7RLvEp/7p9/GvPp xue5B+5E4GeOLWGnwY+u3q3e8jYy+R63uTI62Xke70Z7BrzyfdXs0/9OgIKMUra7 VC4RcGgBDG3SDXGLIhSIpgfiW+ZvKVFF2R0mSnONF4u29tBk7swc/oCqxnbx42oX rOMpPbRo/Pq58dqSL6zeZmksXKKhLjELCtc0ZUmNO7+6klX6rJgpIvrPaIXgwLO4 pj+mELBRCiONdDp7tqxJfD7s0ePRGxX8nppi5C/+aQvoUWwDMIzp1xJ3kDgPiPDH tjFoR4iKI5Rt95Yu2OYQfelcnbCnZIDi6D5yqnMwI+wdnTpAKO3dV8Rw== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Mea91v-E+Wd1; Fri, 18 May 2012 09:02:48 +0100 (IST) Received: from [10.87.48.6] (unknown [86.46.17.139]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 68D5C171473; Fri, 18 May 2012 09:02:46 +0100 (IST) Message-ID: <4FB60226.1010202@cs.tcd.ie> Date: Fri, 18 May 2012 09:02:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Sangster References: <4FB4EA34.2020104@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B881C825E@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> In-Reply-To: <6E79D623502C70419A9EAB18E4D274252B881C825E@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nea@ietf.org" Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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, 18 May 2012 08:02:55 -0000 Hi Paul, On question #1, I'm not sure we're talking about quite the same issue. My concern here isn't security related, its about the complexity of allowing the NEA server to be the TLS client. That causes the spec to be more complex in a bunch of places, adds some work to both implementations and adds complexity to deployments, in that e.g. the NEA server TLS server cert now has to also work as a TLS client cert if you want to use this feature. So my question is really whether the WG are sure you want to keep this feature or not. If the answer is "yes, we want to keep it" that's fine, I'll not stop things moving ahead (I may have to hold my nose a bit though;-). S On 05/17/2012 10:10 PM, Paul Sangster wrote: > Stephen, > > Thanks for all the great feedback, I suspect we would need to do a revision to address everything. Let me respond to question 1 since its mentioned as the primary concern. We've discussed the inbound NEA Server initiated assessments a few times and hadn't ever planned to remove it since it's such a useful feature. Clearly its use comes with some risks that deployers need to account for with countermeasures. Having that feature in the specification allows implementers and deployers to use that feature in a standards based way and an understanding of the risks. > > Personally, I don't view the have every endpoint nail up the TCP connection to the NEA Server for re-assessments as a great solution for everyone (e.g. scaling issues, only usable by AAA server, ...). Allowing customers particularly those with internal deployments inside the enterprise edge firewalls to have network infrastructure devices beside just the AAA server (e.g. compliance/conformance, patch management or security management tools) to reach out to the desktops and perform assessments when network security policies change or as urgent patches are released is a nice feature to allow. > > Endpoint agents could accept only IPsec or TLS protected connections as a countermeasure against many forms of attack on the exposed ports. Leaving the option in allows the deployer to decide what works best with their deployment (scale, product mix, threat model and goals). > > Paul > >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of >> Stephen Farrell >> Sent: Thursday, May 17, 2012 5:08 AM >> To: Stephen Hanna >> Cc: nea@ietf.org >> Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 >> >> >> Hi Steve, >> >> My AD review of this is below. I think question 1 >> is the main one where I have a concern really, the >> others are mostly not-quite-nits or things where I'm >> just asking, or where there'd be an easy fix if >> a change is needed. >> >> I dunno if this will require a revised I-D or not. >> I suspect it will, but will wait for your/the WG's >> response before putting it in that state. Please >> do argue about that if, having seen this review, >> you think this doesn't require another rev. >> >> (And if some of my questions are just dumb, then >> do say, I'm quite used to that:-) >> >> Cheers, >> S. >> >> Questions: >> >> (1) 3.1.1, This says in one place "the NEA Client is >> effectively acting as a TLS server" which I thought was >> going to be more strongly deprecated or entirely removed? >> While you do recommend (RECOMMEND is good 2119 language >> btw) not doing that, it won't work in many cases, so is it >> really worth keeping at all? How about just leaving in the >> first and last paragraphs of 3.1.1? (Would need some more >> edits to fix up, but all of those would simplify the >> document overall.) >> >> (2) 3.3, last sentence: this says "an attack" - is this >> normative instruction meant to apply only for detected >> Asokan attacks, or does it also apply for any other attack >> at all, or for some others? For example, what if the TLS >> handshake terminates fails for some reason not specifically >> stated in this document? What if some new unexpected attack >> on NEA is discovered - would this MUST apply to that? I >> guess choices are to s/an attack/this attack/ if you just >> want this to cover the Asokan attack, or if a more general >> statement is desirable then maybe adding something >> somewhere else would be right. >> >> (3) 3.4.2: How do I know that the "TLS Setup" phase has >> completed and how do I enforce the requirement that TLS >> re-negotiation MUST NOT happen after that? The former seems >> unclear unless it means "after the Finished exchanges" in >> which case maybe say so. The latter seems tricky - will >> current TLS implementations allow you to enforce that? >> >> (4) 3.4.1.1: You do validation according to 5280 which is >> fine. But in 5280, revocation checking is optional. Do you >> need to check revocation here? If you do, then do you need >> to say that the NEA client might need to contact an OCSP >> responder, or is some further profiling of how TLS and 5280 >> are used needed? (e.g. OCSP stapling?) There are a bunch >> of reasonable answers possible and I'm fine with any of 'em >> (particularly whatever folks will implement:-) but I >> suspect you may need to say a bit more here. >> >> (5) 3.4.2.3 - The last sentence is a bit confusing - what >> should happen if a "NEA protocol" may not be able to make >> use of full-duplex? (And maybe s/protocol/implementation/?) >> What do you do if you're one of those or talking to one of >> those? >> >> (6) 3.5: I don't think that enterprise numbers [1] are >> restricted to 24 bits - those are OID arcs which are in >> theory unlimited length. What happens if one is larger than >> 24bits? Reserving a number from that registry also probably >> needs an IANA action, and who knows that might conflict >> with something else. I know you set this to zero but I'm >> guessing vendors will use this as well or its used >> elsewhere by NEA so I do wonder. This also affects 3.9. >> (Nits on this as well: That might also be better stated as >> "Implementations of this specification MUST..." just for >> clarity. And it'd be good to put in a link or reference to >> the IANA registry somewhere - not everyone knows what that >> registry is I guess. Also, referring to 0 as an IETF SMI >> Private Entreprise Number might raise a hackle, since >> that's reserved in the IANA registry. Having said all that, >> if you got this past in other NEA RFCs (didn't check) then >> doing the same thing here is probably ok.) >> >> [1] http://www.iana.org/assignments/enterprise-numbers >> >> (7) 3.5, Message Type. I don't understand what "MUST >> interoperate with other parties despite any differences" >> means here and suspect that that 2119 MUST isn't doable. >> >> (8) 3.5, 6.2 Any "reserved" values should really be >> mentioned in the IANA considerations section so IANA don't >> go and give them out, I mean the 0xffff... ones. "9+" is >> also a bit odd in 6.2. You might want to change that to >> specify the exact range "available for allocation by DE" >> (or whatever is the right term) different from the >> "reserved" value(s) there. >> >> (9) 3.6, is it really ok for the "TLS session initiator" to >> always be the one who proposes the versions in the version >> request message? You still allow the NEA server to be the >> TLS session initiator so what'd happen with this then is >> confusing - the naughty client could get to pick the >> weakest version of PT-TLS that the server supports? 3.7 >> also seems to contradict this, saying that the "PT-TLS >> initiator" sends the version request. Maybe there is some >> cleaning up needed here? >> >> (10) 4.1, are you saying here that if any of these trust >> relationships do not hold, then PT-TLS ought not be used? >> If so, then saying that explicitly would be good. For >> example, it could be that with some implementations, e.g. >> that use less secure inter-proces communications, a bad >> process on a client could invalidate some of these >> assumptions, thus (maybe) making PT-TLS unsafe. >> >> (11) section 5: do you mean the NEA client SHOULD (in 2119 >> terms) provide an indication here? If not, why not? If so, >> what's the criteria for not providing that? (Perhaps if >> there is no UI?) Same should/SHOULD question for the last >> paragraph, i.e. s/should ensure/SHOULD ensure/ and what's >> the exception? >> >> (12) section 6: some of the intro text here is not really >> for IANA, should it be moved elsewhere? (Mainly the >> explanation of PEN handling, which might go up into 3.5 >> perhaps?) >> >> (13) section 6.1: you're asking IANA to act as a repository >> for non-RFC specifications (sort-of), I think that's maybe >> an innovation (not sure) that should be checked out with >> IANA, or maybe you've done that or know of a precedent? >> >> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that >> entries with PEN value 0 need to be IETF stream RFCs, >> or standards-track RFCs, or just RFCs or what? If you >> want the DE to be able to add PEN=0 entries without >> an RFC, I think saying that would be best. >> >> (15) References: can we not make the reference to 4346 (TLS >> 1.1) informative and craft language to make that work? E.g. >> say you SHOULD support TLS1.2 but that in reality a lot of >> people still don't and are only doing 4346 as of now? I >> think if you do that you can argue that TLS 1.1 is not >> a normative reference and that'd be better in future once >> most everyone has caught up with TLS1.2. >> >> Nits: >> >> - 1.4: Not sure its right to talk about the future actions >> of some other organisation in such a definite manner. >> Might be better to say that "the authors understand >> that..." or some other weasel words, or even better would >> be to refer to something the TCG have published if that's >> possible. >> >> - s2, 1st para: maybe s/should use/can use/ just to avoid >> rfc 2119 confusion. >> >> - 2.1, why use the "underlying carrier protocol" when only >> TCP is covered here? >> >> - 2.4, I'm not clear why this section is (still) needed. >> It tries to say, but I don't get it. Did you once want to >> control what ciphersuites could be used by TLS as part of >> NEA? No problem with it staying though. >> >> - 3.1.2, last sentence, s/must/MUST/? or s/must/needs to >> be/? >> >> - 3.4.2, s/normally starts/starts/ how else can it work? >> Also not quite correct to say the connection triggers TLS >> h/s - the sending/listening processes do that. >> >> - 3.4.2.2: The end of this phase is also a little >> ambiguous. You say we're done when the NEA server has sent >> an empty list of sasl mechanisms after all NEA client >> authentications are done. But then you also say that the >> NEA server can choose to not authenticate the client and >> move on. But how would the client know that the PT-TLS >> negotiation phase is over in that case? Ah, 3.8.3 clears >> this up. Might be worth clarifying that a bit in 3.4.2.2. >> >> - 3.5, Message Id. Since receivers have to handle roll >> over, there doesn't seem to be a need for a MUST start at >> zero, is there? And maybe you don't even really need the >> MUST monotonically increasing either? (Aside: I generally >> prefer if senders can start randomly anyway, just in case >> there's some message guessing threat - never any harm to >> make that harder IMO.) >> >> - 3.5, message length: your answer here is probably "no," >> which is fine, but I wondered if there's any useful >> guidance about over-long messages that could be given? E.g. >> could a NEA client try send a (number of) 2^31 byte >> payload(s) to DoS the server in the hope that the server >> would then fail-open? (I note that the TLS plaintext max >> is 2^14 bytes in one record, dunno if that might be a >> factor here or not to be honest.) >> >> - 3.6, seems off for a standards track RFC to distinguish >> between production code and something else, maybe that >> could be better phrased? >> >> - 3.6, PB-TNC batch: total and utter nit:-) The reference >> to section 4 of the PB-TNC spec is rendered with the wrong >> URL in the tools.ietf.org version of the draft. >> (Interpreted as a link to section 4 of this.) I think if >> you added the RFC number for PB-TNC it might help there. >> >> - 3.8, 2nd last para, maybe s/may require/MAY require/ ? >> >> - 3.8.5.4, maybe s/may trigger/MAY trigger/ ? >> >> - section 6, s/requests the IANA/requests that IANA/? >> >> - 6.2, "Once this document becomes an RFC..." probably >> ought be deleted. Easier if that's a separate paragraph >> with an instruction to the RFC editor as to what to delete, >> which is not all of the paragraph in this case I think. >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea > > > > From Paul_Sangster@symantec.com Fri May 18 09:46:51 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018C321F8720 for ; Fri, 18 May 2012 09:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.675 X-Spam-Level: X-Spam-Status: No, score=-3.675 tagged_above=-999 required=5 tests=[AWL=-0.975, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 QPpqB2Sg9LGi for ; Fri, 18 May 2012 09:46:49 -0700 (PDT) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4B921F8723 for ; Fri, 18 May 2012 09:46:49 -0700 (PDT) X-AuditID: d80ac3f2-b7f666d000006a7a-9f-4fb67cf8c081 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 B9.35.27258.8FC76BF4; Fri, 18 May 2012 16:46:48 +0000 (GMT) Received: from [155.64.220.137] (helo=TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM) by tus1smtintpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1SVQKG-0006AR-GR; Fri, 18 May 2012 16:46:48 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([169.254.188.134]) by TUS1XCHHUBPIN01.SYMC.SYMANTEC.COM ([155.64.220.137]) with mapi; Fri, 18 May 2012 09:46:48 -0700 From: Paul Sangster To: Stephen Farrell Date: Fri, 18 May 2012 09:47:11 -0700 Thread-Topic: [Nea] AD review of draft-ietf-nea-pt-tls-04 Thread-Index: Ac00zMD4oQF5Vo2VRGmbHwRJ51bYLgASFfRQ Message-ID: <6E79D623502C70419A9EAB18E4D274252B881C8705@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4FB4EA34.2020104@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B881C825E@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FB60226.1010202@cs.tcd.ie> In-Reply-To: <4FB60226.1010202@cs.tcd.ie> 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+NgFlrGIsWRmVeSWpSXmKPExsVyYMX1NN0fNdv8DRZ/Urb4/LbC4vG5U8wW 0/deY3dg9ljbfZXNY8mSn0we15uusgcwR3HZpKTmZJalFunbJXBlbF/5gLWgtbBizbRGlgbG BxFdjJwcEgImEjv39zNB2GISF+6tZ+ti5OIQEvjIKLHq7md2COc1o8SWb9MYIZzVjBI/Z61k B2lhEzCQ2HnkFJgtIqAvsXfzOTCbWcBVYmfjBzCbRUBVYs/132ArhAUsJG4tWMwIUW8pceTS JxYI20ji+e6DYHFegSiJY89mg9ULCdxilNj01RDE5hTQlOj5fZUVxGYEOvX7qTVMELvEJW49 mQ/1goDEkj3nmSFsUYmXj/9B1YtK3GlfzwhRryOxYPcnNghbW2LZwtfMEHsFJU7OfMIygVF8 FpKxs5C0zELSMgtJywJGllWMMiWlxYbFuSX5pSUFqRUGRnrFlbmJwLhL1kvOz93ECIy9G1yH P+1gvLFU8RCjAAejEg/v5Ypt/kKsiWVAlYcYJTiYlUR4C9SAQrwpiZVVqUX58UWlOanFhxil OViUxHk/7N7qLySQnliSmp2aWpBaBJNl4uCUamCc/iYo6VhesTqjxrTddfJKk94frTCyLv4/ 0WEBJ+tdtxL2e1ctJzll6xdKZxhuW9rWIdw8w727PqDn5zG1LN+JPa8v3j2W/o1JbFHzjabv 9ZWCYpbzi41OivzboXw1o21ax5NHR5wSsyefnFfftbC2vz88flGHrkXczdzd6j5PLhRZftLv 11diKc5INNRiLipOBADIyf2TuQIAAA== Cc: "nea@ietf.org" Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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, 18 May 2012 16:46:51 -0000 Thanks, I agree we were looking at different angles on this issue. I perso= nally do think it's worth leaving this feature in the protocol specificatio= n as it is very useful to provide an alternative to nailing up (potentially= ) huge numbers of connections to the AAA server and enabling for other netw= ork infrastructure devices to perform assessments (as discussed below). However, I do appreciate that implementers of some products may not wish to= address these issues, so I think it makes sense for it to be an optional t= o implement feature (particularly on the client).=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Friday, May 18, 2012 1:03 AM > To: Paul Sangster > Cc: Stephen Hanna; nea@ietf.org > Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 >=20 >=20 > Hi Paul, >=20 > On question #1, I'm not sure we're talking about > quite the same issue. >=20 > My concern here isn't security related, its about the > complexity of allowing the NEA server to be the > TLS client. That causes the spec to be more complex > in a bunch of places, adds some work to both > implementations and adds complexity to deployments, > in that e.g. the NEA server TLS server cert now has > to also work as a TLS client cert if you want to > use this feature. >=20 > So my question is really whether the WG are sure > you want to keep this feature or not. If the answer > is "yes, we want to keep it" that's fine, I'll not > stop things moving ahead (I may have to hold my > nose a bit though;-). >=20 > S >=20 >=20 > On 05/17/2012 10:10 PM, Paul Sangster wrote: > > Stephen, > > > > Thanks for all the great feedback, I suspect we would need to do a > revision to address everything. Let me respond to question 1 since its > mentioned as the primary concern. We've discussed the inbound NEA > Server initiated assessments a few times and hadn't ever planned to > remove it since it's such a useful feature. Clearly its use comes with > some risks that deployers need to account for with countermeasures. > Having that feature in the specification allows implementers and > deployers to use that feature in a standards based way and an > understanding of the risks. > > > > Personally, I don't view the have every endpoint nail up the TCP > connection to the NEA Server for re-assessments as a great solution for > everyone (e.g. scaling issues, only usable by AAA server, ...). > Allowing customers particularly those with internal deployments inside > the enterprise edge firewalls to have network infrastructure devices > beside just the AAA server (e.g. compliance/conformance, patch > management or security management tools) to reach out to the desktops > and perform assessments when network security policies change or as > urgent patches are released is a nice feature to allow. > > > > Endpoint agents could accept only IPsec or TLS protected connections > as a countermeasure against many forms of attack on the exposed ports. > Leaving the option in allows the deployer to decide what works best > with their deployment (scale, product mix, threat model and goals). > > > > Paul > > > >> -----Original Message----- > >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf > Of > >> Stephen Farrell > >> Sent: Thursday, May 17, 2012 5:08 AM > >> To: Stephen Hanna > >> Cc: nea@ietf.org > >> Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 > >> > >> > >> Hi Steve, > >> > >> My AD review of this is below. I think question 1 > >> is the main one where I have a concern really, the > >> others are mostly not-quite-nits or things where I'm > >> just asking, or where there'd be an easy fix if > >> a change is needed. > >> > >> I dunno if this will require a revised I-D or not. > >> I suspect it will, but will wait for your/the WG's > >> response before putting it in that state. Please > >> do argue about that if, having seen this review, > >> you think this doesn't require another rev. > >> > >> (And if some of my questions are just dumb, then > >> do say, I'm quite used to that:-) > >> > >> Cheers, > >> S. > >> > >> Questions: > >> > >> (1) 3.1.1, This says in one place "the NEA Client is > >> effectively acting as a TLS server" which I thought was > >> going to be more strongly deprecated or entirely removed? > >> While you do recommend (RECOMMEND is good 2119 language > >> btw) not doing that, it won't work in many cases, so is it > >> really worth keeping at all? How about just leaving in the > >> first and last paragraphs of 3.1.1? (Would need some more > >> edits to fix up, but all of those would simplify the > >> document overall.) > >> > >> (2) 3.3, last sentence: this says "an attack" - is this > >> normative instruction meant to apply only for detected > >> Asokan attacks, or does it also apply for any other attack > >> at all, or for some others? For example, what if the TLS > >> handshake terminates fails for some reason not specifically > >> stated in this document? What if some new unexpected attack > >> on NEA is discovered - would this MUST apply to that? I > >> guess choices are to s/an attack/this attack/ if you just > >> want this to cover the Asokan attack, or if a more general > >> statement is desirable then maybe adding something > >> somewhere else would be right. > >> > >> (3) 3.4.2: How do I know that the "TLS Setup" phase has > >> completed and how do I enforce the requirement that TLS > >> re-negotiation MUST NOT happen after that? The former seems > >> unclear unless it means "after the Finished exchanges" in > >> which case maybe say so. The latter seems tricky - will > >> current TLS implementations allow you to enforce that? > >> > >> (4) 3.4.1.1: You do validation according to 5280 which is > >> fine. But in 5280, revocation checking is optional. Do you > >> need to check revocation here? If you do, then do you need > >> to say that the NEA client might need to contact an OCSP > >> responder, or is some further profiling of how TLS and 5280 > >> are used needed? (e.g. OCSP stapling?) There are a bunch > >> of reasonable answers possible and I'm fine with any of 'em > >> (particularly whatever folks will implement:-) but I > >> suspect you may need to say a bit more here. > >> > >> (5) 3.4.2.3 - The last sentence is a bit confusing - what > >> should happen if a "NEA protocol" may not be able to make > >> use of full-duplex? (And maybe s/protocol/implementation/?) > >> What do you do if you're one of those or talking to one of > >> those? > >> > >> (6) 3.5: I don't think that enterprise numbers [1] are > >> restricted to 24 bits - those are OID arcs which are in > >> theory unlimited length. What happens if one is larger than > >> 24bits? Reserving a number from that registry also probably > >> needs an IANA action, and who knows that might conflict > >> with something else. I know you set this to zero but I'm > >> guessing vendors will use this as well or its used > >> elsewhere by NEA so I do wonder. This also affects 3.9. > >> (Nits on this as well: That might also be better stated as > >> "Implementations of this specification MUST..." just for > >> clarity. And it'd be good to put in a link or reference to > >> the IANA registry somewhere - not everyone knows what that > >> registry is I guess. Also, referring to 0 as an IETF SMI > >> Private Entreprise Number might raise a hackle, since > >> that's reserved in the IANA registry. Having said all that, > >> if you got this past in other NEA RFCs (didn't check) then > >> doing the same thing here is probably ok.) > >> > >> [1] http://www.iana.org/assignments/enterprise-numbers > >> > >> (7) 3.5, Message Type. I don't understand what "MUST > >> interoperate with other parties despite any differences" > >> means here and suspect that that 2119 MUST isn't doable. > >> > >> (8) 3.5, 6.2 Any "reserved" values should really be > >> mentioned in the IANA considerations section so IANA don't > >> go and give them out, I mean the 0xffff... ones. "9+" is > >> also a bit odd in 6.2. You might want to change that to > >> specify the exact range "available for allocation by DE" > >> (or whatever is the right term) different from the > >> "reserved" value(s) there. > >> > >> (9) 3.6, is it really ok for the "TLS session initiator" to > >> always be the one who proposes the versions in the version > >> request message? You still allow the NEA server to be the > >> TLS session initiator so what'd happen with this then is > >> confusing - the naughty client could get to pick the > >> weakest version of PT-TLS that the server supports? 3.7 > >> also seems to contradict this, saying that the "PT-TLS > >> initiator" sends the version request. Maybe there is some > >> cleaning up needed here? > >> > >> (10) 4.1, are you saying here that if any of these trust > >> relationships do not hold, then PT-TLS ought not be used? > >> If so, then saying that explicitly would be good. For > >> example, it could be that with some implementations, e.g. > >> that use less secure inter-proces communications, a bad > >> process on a client could invalidate some of these > >> assumptions, thus (maybe) making PT-TLS unsafe. > >> > >> (11) section 5: do you mean the NEA client SHOULD (in 2119 > >> terms) provide an indication here? If not, why not? If so, > >> what's the criteria for not providing that? (Perhaps if > >> there is no UI?) Same should/SHOULD question for the last > >> paragraph, i.e. s/should ensure/SHOULD ensure/ and what's > >> the exception? > >> > >> (12) section 6: some of the intro text here is not really > >> for IANA, should it be moved elsewhere? (Mainly the > >> explanation of PEN handling, which might go up into 3.5 > >> perhaps?) > >> > >> (13) section 6.1: you're asking IANA to act as a repository > >> for non-RFC specifications (sort-of), I think that's maybe > >> an innovation (not sure) that should be checked out with > >> IANA, or maybe you've done that or know of a precedent? > >> > >> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that > >> entries with PEN value 0 need to be IETF stream RFCs, > >> or standards-track RFCs, or just RFCs or what? If you > >> want the DE to be able to add PEN=3D0 entries without > >> an RFC, I think saying that would be best. > >> > >> (15) References: can we not make the reference to 4346 (TLS > >> 1.1) informative and craft language to make that work? E.g. > >> say you SHOULD support TLS1.2 but that in reality a lot of > >> people still don't and are only doing 4346 as of now? I > >> think if you do that you can argue that TLS 1.1 is not > >> a normative reference and that'd be better in future once > >> most everyone has caught up with TLS1.2. > >> > >> Nits: > >> > >> - 1.4: Not sure its right to talk about the future actions > >> of some other organisation in such a definite manner. > >> Might be better to say that "the authors understand > >> that..." or some other weasel words, or even better would > >> be to refer to something the TCG have published if that's > >> possible. > >> > >> - s2, 1st para: maybe s/should use/can use/ just to avoid > >> rfc 2119 confusion. > >> > >> - 2.1, why use the "underlying carrier protocol" when only > >> TCP is covered here? > >> > >> - 2.4, I'm not clear why this section is (still) needed. > >> It tries to say, but I don't get it. Did you once want to > >> control what ciphersuites could be used by TLS as part of > >> NEA? No problem with it staying though. > >> > >> - 3.1.2, last sentence, s/must/MUST/? or s/must/needs to > >> be/? > >> > >> - 3.4.2, s/normally starts/starts/ how else can it work? > >> Also not quite correct to say the connection triggers TLS > >> h/s - the sending/listening processes do that. > >> > >> - 3.4.2.2: The end of this phase is also a little > >> ambiguous. You say we're done when the NEA server has sent > >> an empty list of sasl mechanisms after all NEA client > >> authentications are done. But then you also say that the > >> NEA server can choose to not authenticate the client and > >> move on. But how would the client know that the PT-TLS > >> negotiation phase is over in that case? Ah, 3.8.3 clears > >> this up. Might be worth clarifying that a bit in 3.4.2.2. > >> > >> - 3.5, Message Id. Since receivers have to handle roll > >> over, there doesn't seem to be a need for a MUST start at > >> zero, is there? And maybe you don't even really need the > >> MUST monotonically increasing either? (Aside: I generally > >> prefer if senders can start randomly anyway, just in case > >> there's some message guessing threat - never any harm to > >> make that harder IMO.) > >> > >> - 3.5, message length: your answer here is probably "no," > >> which is fine, but I wondered if there's any useful > >> guidance about over-long messages that could be given? E.g. > >> could a NEA client try send a (number of) 2^31 byte > >> payload(s) to DoS the server in the hope that the server > >> would then fail-open? (I note that the TLS plaintext max > >> is 2^14 bytes in one record, dunno if that might be a > >> factor here or not to be honest.) > >> > >> - 3.6, seems off for a standards track RFC to distinguish > >> between production code and something else, maybe that > >> could be better phrased? > >> > >> - 3.6, PB-TNC batch: total and utter nit:-) The reference > >> to section 4 of the PB-TNC spec is rendered with the wrong > >> URL in the tools.ietf.org version of the draft. > >> (Interpreted as a link to section 4 of this.) I think if > >> you added the RFC number for PB-TNC it might help there. > >> > >> - 3.8, 2nd last para, maybe s/may require/MAY require/ ? > >> > >> - 3.8.5.4, maybe s/may trigger/MAY trigger/ ? > >> > >> - section 6, s/requests the IANA/requests that IANA/? > >> > >> - 6.2, "Once this document becomes an RFC..." probably > >> ought be deleted. Easier if that's a separate paragraph > >> with an instruction to the RFC editor as to what to delete, > >> which is not all of the paragraph in this case I think. > >> > >> _______________________________________________ > >> Nea mailing list > >> Nea@ietf.org > >> https://www.ietf.org/mailman/listinfo/nea > > > > > > > > From shanna@juniper.net Tue May 22 12:27:53 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177A721F8606 for ; Tue, 22 May 2012 12:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.905 X-Spam-Level: X-Spam-Status: No, score=-103.905 tagged_above=-999 required=5 tests=[AWL=-1.205, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 t3ck32csHSWf for ; Tue, 22 May 2012 12:27:51 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3233921F8603 for ; Tue, 22 May 2012 12:27:47 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT7vostwB6k+BzT4RERe+P/em9n7x9GpG@postini.com; Tue, 22 May 2012 12:27:51 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 22 May 2012 12:25:08 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 22 May 2012 15:25:07 -0400 From: Stephen Hanna To: Paul Sangster , Stephen Farrell Date: Tue, 22 May 2012 15:25:05 -0400 Thread-Topic: [Nea] AD review of draft-ietf-nea-pt-tls-04 Thread-Index: Ac00zMD4oQF5Vo2VRGmbHwRJ51bYLgASFfRQAM5XHYA= Message-ID: References: <4FB4EA34.2020104@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B881C825E@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FB60226.1010202@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B881C8705@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> In-Reply-To: <6E79D623502C70419A9EAB18E4D274252B881C8705@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 Cc: "nea@ietf.org" Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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, 22 May 2012 19:27:53 -0000 Stephen Farrell wrote: > So my question is really whether the WG are sure > you want to keep this feature or not. While server-initiated PT-TLS sessions are not my favorite part of PT-TLS, this feature is clearly required by the use cases in RFC 5209 (NEA Overview and Requirements). Section 6.2.2 of that spec describes several situations where the NEA Server may need to initiate a reassessment: periodic, event-based, and in response to policy updates. One way to do this is to require each endpoint to always maintain a TLS connection to a NEA Server. But this is a lot of overhead so section 6.2.2.2 of RFC 5209 describes an approach where the NEA Server reaches out to NEA Clients as needed. This use case was agreed to by the NEA WG and the IETF and the IESG more than four years ago. Clearly, it represented rough consensus at the time. Since then, we've spent a good deal of WG time creating this spec to meet the use case, including changes just a few months ago to describe in more detail how certificates should be handled for this case. The WG is well aware of the ugliness involved. Therefore, I conclude that we still have rough WG consensus in favor of keeping server-initiated sessions as an optional feature. Stephen, please let me know if you want me to run a formal consensus check to verify this. And thanks for all your careful review. This is a good issue to raise. It's the least elegant part of the protocol and should only be included if there's a driving reason to do so and a strong WG consensus that we should include it. But I believe based on what I've seen that we have both the reason and the consensus. Thanks, Steve > -----Original Message----- > From: Paul Sangster [mailto:Paul_Sangster@symantec.com] > Sent: Friday, May 18, 2012 12:47 PM > To: Stephen Farrell > Cc: Stephen Hanna; nea@ietf.org > Subject: RE: [Nea] AD review of draft-ietf-nea-pt-tls-04 > > Thanks, I agree we were looking at different angles on this issue. I > personally do think it's worth leaving this feature in the protocol > specification as it is very useful to provide an alternative to nailing > up (potentially) huge numbers of connections to the AAA server and > enabling for other network infrastructure devices to perform > assessments (as discussed below). > > However, I do appreciate that implementers of some products may not > wish to address these issues, so I think it makes sense for it to be an > optional to implement feature (particularly on the client). > > > -----Original Message----- > > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > > Sent: Friday, May 18, 2012 1:03 AM > > To: Paul Sangster > > Cc: Stephen Hanna; nea@ietf.org > > Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 > > > > > > Hi Paul, > > > > On question #1, I'm not sure we're talking about > > quite the same issue. > > > > My concern here isn't security related, its about the > > complexity of allowing the NEA server to be the > > TLS client. That causes the spec to be more complex > > in a bunch of places, adds some work to both > > implementations and adds complexity to deployments, > > in that e.g. the NEA server TLS server cert now has > > to also work as a TLS client cert if you want to > > use this feature. > > > > So my question is really whether the WG are sure > > you want to keep this feature or not. If the answer > > is "yes, we want to keep it" that's fine, I'll not > > stop things moving ahead (I may have to hold my > > nose a bit though;-). > > > > S > > > > > > On 05/17/2012 10:10 PM, Paul Sangster wrote: > > > Stephen, > > > > > > Thanks for all the great feedback, I suspect we would need to do a > > revision to address everything. Let me respond to question 1 since > its > > mentioned as the primary concern. We've discussed the inbound NEA > > Server initiated assessments a few times and hadn't ever planned to > > remove it since it's such a useful feature. Clearly its use comes > with > > some risks that deployers need to account for with countermeasures. > > Having that feature in the specification allows implementers and > > deployers to use that feature in a standards based way and an > > understanding of the risks. > > > > > > Personally, I don't view the have every endpoint nail up the TCP > > connection to the NEA Server for re-assessments as a great solution > for > > everyone (e.g. scaling issues, only usable by AAA server, ...). > > Allowing customers particularly those with internal deployments > inside > > the enterprise edge firewalls to have network infrastructure devices > > beside just the AAA server (e.g. compliance/conformance, patch > > management or security management tools) to reach out to the desktops > > and perform assessments when network security policies change or as > > urgent patches are released is a nice feature to allow. > > > > > > Endpoint agents could accept only IPsec or TLS protected > connections > > as a countermeasure against many forms of attack on the exposed > ports. > > Leaving the option in allows the deployer to decide what works best > > with their deployment (scale, product mix, threat model and goals). > > > > > > Paul > > > > > >> -----Original Message----- > > >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf > > Of > > >> Stephen Farrell > > >> Sent: Thursday, May 17, 2012 5:08 AM > > >> To: Stephen Hanna > > >> Cc: nea@ietf.org > > >> Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 > > >> > > >> > > >> Hi Steve, > > >> > > >> My AD review of this is below. I think question 1 > > >> is the main one where I have a concern really, the > > >> others are mostly not-quite-nits or things where I'm > > >> just asking, or where there'd be an easy fix if > > >> a change is needed. > > >> > > >> I dunno if this will require a revised I-D or not. > > >> I suspect it will, but will wait for your/the WG's > > >> response before putting it in that state. Please > > >> do argue about that if, having seen this review, > > >> you think this doesn't require another rev. > > >> > > >> (And if some of my questions are just dumb, then > > >> do say, I'm quite used to that:-) > > >> > > >> Cheers, > > >> S. > > >> > > >> Questions: > > >> > > >> (1) 3.1.1, This says in one place "the NEA Client is > > >> effectively acting as a TLS server" which I thought was > > >> going to be more strongly deprecated or entirely removed? > > >> While you do recommend (RECOMMEND is good 2119 language > > >> btw) not doing that, it won't work in many cases, so is it > > >> really worth keeping at all? How about just leaving in the > > >> first and last paragraphs of 3.1.1? (Would need some more > > >> edits to fix up, but all of those would simplify the > > >> document overall.) > > >> > > >> (2) 3.3, last sentence: this says "an attack" - is this > > >> normative instruction meant to apply only for detected > > >> Asokan attacks, or does it also apply for any other attack > > >> at all, or for some others? For example, what if the TLS > > >> handshake terminates fails for some reason not specifically > > >> stated in this document? What if some new unexpected attack > > >> on NEA is discovered - would this MUST apply to that? I > > >> guess choices are to s/an attack/this attack/ if you just > > >> want this to cover the Asokan attack, or if a more general > > >> statement is desirable then maybe adding something > > >> somewhere else would be right. > > >> > > >> (3) 3.4.2: How do I know that the "TLS Setup" phase has > > >> completed and how do I enforce the requirement that TLS > > >> re-negotiation MUST NOT happen after that? The former seems > > >> unclear unless it means "after the Finished exchanges" in > > >> which case maybe say so. The latter seems tricky - will > > >> current TLS implementations allow you to enforce that? > > >> > > >> (4) 3.4.1.1: You do validation according to 5280 which is > > >> fine. But in 5280, revocation checking is optional. Do you > > >> need to check revocation here? If you do, then do you need > > >> to say that the NEA client might need to contact an OCSP > > >> responder, or is some further profiling of how TLS and 5280 > > >> are used needed? (e.g. OCSP stapling?) There are a bunch > > >> of reasonable answers possible and I'm fine with any of 'em > > >> (particularly whatever folks will implement:-) but I > > >> suspect you may need to say a bit more here. > > >> > > >> (5) 3.4.2.3 - The last sentence is a bit confusing - what > > >> should happen if a "NEA protocol" may not be able to make > > >> use of full-duplex? (And maybe s/protocol/implementation/?) > > >> What do you do if you're one of those or talking to one of > > >> those? > > >> > > >> (6) 3.5: I don't think that enterprise numbers [1] are > > >> restricted to 24 bits - those are OID arcs which are in > > >> theory unlimited length. What happens if one is larger than > > >> 24bits? Reserving a number from that registry also probably > > >> needs an IANA action, and who knows that might conflict > > >> with something else. I know you set this to zero but I'm > > >> guessing vendors will use this as well or its used > > >> elsewhere by NEA so I do wonder. This also affects 3.9. > > >> (Nits on this as well: That might also be better stated as > > >> "Implementations of this specification MUST..." just for > > >> clarity. And it'd be good to put in a link or reference to > > >> the IANA registry somewhere - not everyone knows what that > > >> registry is I guess. Also, referring to 0 as an IETF SMI > > >> Private Entreprise Number might raise a hackle, since > > >> that's reserved in the IANA registry. Having said all that, > > >> if you got this past in other NEA RFCs (didn't check) then > > >> doing the same thing here is probably ok.) > > >> > > >> [1] http://www.iana.org/assignments/enterprise-numbers > > >> > > >> (7) 3.5, Message Type. I don't understand what "MUST > > >> interoperate with other parties despite any differences" > > >> means here and suspect that that 2119 MUST isn't doable. > > >> > > >> (8) 3.5, 6.2 Any "reserved" values should really be > > >> mentioned in the IANA considerations section so IANA don't > > >> go and give them out, I mean the 0xffff... ones. "9+" is > > >> also a bit odd in 6.2. You might want to change that to > > >> specify the exact range "available for allocation by DE" > > >> (or whatever is the right term) different from the > > >> "reserved" value(s) there. > > >> > > >> (9) 3.6, is it really ok for the "TLS session initiator" to > > >> always be the one who proposes the versions in the version > > >> request message? You still allow the NEA server to be the > > >> TLS session initiator so what'd happen with this then is > > >> confusing - the naughty client could get to pick the > > >> weakest version of PT-TLS that the server supports? 3.7 > > >> also seems to contradict this, saying that the "PT-TLS > > >> initiator" sends the version request. Maybe there is some > > >> cleaning up needed here? > > >> > > >> (10) 4.1, are you saying here that if any of these trust > > >> relationships do not hold, then PT-TLS ought not be used? > > >> If so, then saying that explicitly would be good. For > > >> example, it could be that with some implementations, e.g. > > >> that use less secure inter-proces communications, a bad > > >> process on a client could invalidate some of these > > >> assumptions, thus (maybe) making PT-TLS unsafe. > > >> > > >> (11) section 5: do you mean the NEA client SHOULD (in 2119 > > >> terms) provide an indication here? If not, why not? If so, > > >> what's the criteria for not providing that? (Perhaps if > > >> there is no UI?) Same should/SHOULD question for the last > > >> paragraph, i.e. s/should ensure/SHOULD ensure/ and what's > > >> the exception? > > >> > > >> (12) section 6: some of the intro text here is not really > > >> for IANA, should it be moved elsewhere? (Mainly the > > >> explanation of PEN handling, which might go up into 3.5 > > >> perhaps?) > > >> > > >> (13) section 6.1: you're asking IANA to act as a repository > > >> for non-RFC specifications (sort-of), I think that's maybe > > >> an innovation (not sure) that should be checked out with > > >> IANA, or maybe you've done that or know of a precedent? > > >> > > >> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that > > >> entries with PEN value 0 need to be IETF stream RFCs, > > >> or standards-track RFCs, or just RFCs or what? If you > > >> want the DE to be able to add PEN=3D0 entries without > > >> an RFC, I think saying that would be best. > > >> > > >> (15) References: can we not make the reference to 4346 (TLS > > >> 1.1) informative and craft language to make that work? E.g. > > >> say you SHOULD support TLS1.2 but that in reality a lot of > > >> people still don't and are only doing 4346 as of now? I > > >> think if you do that you can argue that TLS 1.1 is not > > >> a normative reference and that'd be better in future once > > >> most everyone has caught up with TLS1.2. > > >> > > >> Nits: > > >> > > >> - 1.4: Not sure its right to talk about the future actions > > >> of some other organisation in such a definite manner. > > >> Might be better to say that "the authors understand > > >> that..." or some other weasel words, or even better would > > >> be to refer to something the TCG have published if that's > > >> possible. > > >> > > >> - s2, 1st para: maybe s/should use/can use/ just to avoid > > >> rfc 2119 confusion. > > >> > > >> - 2.1, why use the "underlying carrier protocol" when only > > >> TCP is covered here? > > >> > > >> - 2.4, I'm not clear why this section is (still) needed. > > >> It tries to say, but I don't get it. Did you once want to > > >> control what ciphersuites could be used by TLS as part of > > >> NEA? No problem with it staying though. > > >> > > >> - 3.1.2, last sentence, s/must/MUST/? or s/must/needs to > > >> be/? > > >> > > >> - 3.4.2, s/normally starts/starts/ how else can it work? > > >> Also not quite correct to say the connection triggers TLS > > >> h/s - the sending/listening processes do that. > > >> > > >> - 3.4.2.2: The end of this phase is also a little > > >> ambiguous. You say we're done when the NEA server has sent > > >> an empty list of sasl mechanisms after all NEA client > > >> authentications are done. But then you also say that the > > >> NEA server can choose to not authenticate the client and > > >> move on. But how would the client know that the PT-TLS > > >> negotiation phase is over in that case? Ah, 3.8.3 clears > > >> this up. Might be worth clarifying that a bit in 3.4.2.2. > > >> > > >> - 3.5, Message Id. Since receivers have to handle roll > > >> over, there doesn't seem to be a need for a MUST start at > > >> zero, is there? And maybe you don't even really need the > > >> MUST monotonically increasing either? (Aside: I generally > > >> prefer if senders can start randomly anyway, just in case > > >> there's some message guessing threat - never any harm to > > >> make that harder IMO.) > > >> > > >> - 3.5, message length: your answer here is probably "no," > > >> which is fine, but I wondered if there's any useful > > >> guidance about over-long messages that could be given? E.g. > > >> could a NEA client try send a (number of) 2^31 byte > > >> payload(s) to DoS the server in the hope that the server > > >> would then fail-open? (I note that the TLS plaintext max > > >> is 2^14 bytes in one record, dunno if that might be a > > >> factor here or not to be honest.) > > >> > > >> - 3.6, seems off for a standards track RFC to distinguish > > >> between production code and something else, maybe that > > >> could be better phrased? > > >> > > >> - 3.6, PB-TNC batch: total and utter nit:-) The reference > > >> to section 4 of the PB-TNC spec is rendered with the wrong > > >> URL in the tools.ietf.org version of the draft. > > >> (Interpreted as a link to section 4 of this.) I think if > > >> you added the RFC number for PB-TNC it might help there. > > >> > > >> - 3.8, 2nd last para, maybe s/may require/MAY require/ ? > > >> > > >> - 3.8.5.4, maybe s/may trigger/MAY trigger/ ? > > >> > > >> - section 6, s/requests the IANA/requests that IANA/? > > >> > > >> - 6.2, "Once this document becomes an RFC..." probably > > >> ought be deleted. Easier if that's a separate paragraph > > >> with an instruction to the RFC editor as to what to delete, > > >> which is not all of the paragraph in this case I think. > > >> > > >> _______________________________________________ > > >> Nea mailing list > > >> Nea@ietf.org > > >> https://www.ietf.org/mailman/listinfo/nea > > > > > > > > > > > > From stephen.farrell@cs.tcd.ie Tue May 22 12:42:21 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B3221F8681 for ; Tue, 22 May 2012 12:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.304 X-Spam-Level: X-Spam-Status: No, score=-97.304 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, MIME_QP_LONG_LINE=1.396, 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 t-f4pzx207Qi for ; Tue, 22 May 2012 12:42:19 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C4DD921F8680 for ; Tue, 22 May 2012 12:42:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E4DAC153B09; Tue, 22 May 2012 20:42:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1337715734; bh=Bq30R gBtBQiQ4MbRlgugyPGShrDtgBcI+kuJxmQpnCs=; b=W5ftFO5OH4IeHq/NJWHfO qllG+83bMI+skAyO+5QcLf42KfYWhHGlMYINchP6rpSKVwXMsGEbjxHdyL0FWUsA a5R9x4fZeGaV0UPF5u39aJFhHRWDBS2et/fw9Kc3M+Zb7+QTQL6RsKYC5YMjGHz6 +w2TNYrgD4kvNKie2cVrWB8EcCj6MoRqGZP01YytAhRDLaomdAb5HgZEmJ+YsmX3 N//Mv9XO6TX5KGic66jBhgVNkx1oUokBKbm+BPMZpTVJBBq6q7g6NyXJamhRiDtU Zg+wXwCxb66jRhfUx9+v9YCDUxLeZazY1YR+Up1p87Kqvzw/KCEZkpJjpl7rnAx2 w== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Omn56T+ZG4SX; Tue, 22 May 2012 20:42:14 +0100 (IST) Received: from [10.87.48.5] (unknown [86.46.24.206]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DB799153B03; Tue, 22 May 2012 20:42:13 +0100 (IST) References: <4FB4EA34.2020104@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B881C825E@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FB60226.1010202@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B881C8705@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9B206) From: Stephen Farrell Date: Tue, 22 May 2012 20:41:54 +0100 To: Stephen Hanna Cc: "nea@ietf.org" Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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, 22 May 2012 19:42:21 -0000 That's fine Steve, like I said I wanted to check. Can you get back to me as to whether any of the other questions warrant a re= vised I-D? Cheers, S On 22 May 2012, at 20:25, Stephen Hanna wrote: > Stephen Farrell wrote: >> So my question is really whether the WG are sure >> you want to keep this feature or not. >=20 > While server-initiated PT-TLS sessions are not my favorite > part of PT-TLS, this feature is clearly required by the use > cases in RFC 5209 (NEA Overview and Requirements). Section > 6.2.2 of that spec describes several situations where the > NEA Server may need to initiate a reassessment: periodic, > event-based, and in response to policy updates. One way to > do this is to require each endpoint to always maintain a TLS > connection to a NEA Server. But this is a lot of overhead so > section 6.2.2.2 of RFC 5209 describes an approach where the > NEA Server reaches out to NEA Clients as needed. >=20 > This use case was agreed to by the NEA WG and the IETF and the > IESG more than four years ago. Clearly, it represented rough > consensus at the time. Since then, we've spent a good deal of > WG time creating this spec to meet the use case, including > changes just a few months ago to describe in more detail how > certificates should be handled for this case. The WG is well > aware of the ugliness involved. >=20 > Therefore, I conclude that we still have rough WG consensus in > favor of keeping server-initiated sessions as an optional > feature. Stephen, please let me know if you want me to run a > formal consensus check to verify this. >=20 > And thanks for all your careful review. This is a good issue > to raise. It's the least elegant part of the protocol and should > only be included if there's a driving reason to do so and a > strong WG consensus that we should include it. But I believe > based on what I've seen that we have both the reason and the > consensus. >=20 > Thanks, >=20 > Steve >=20 >> -----Original Message----- >> From: Paul Sangster [mailto:Paul_Sangster@symantec.com] >> Sent: Friday, May 18, 2012 12:47 PM >> To: Stephen Farrell >> Cc: Stephen Hanna; nea@ietf.org >> Subject: RE: [Nea] AD review of draft-ietf-nea-pt-tls-04 >>=20 >> Thanks, I agree we were looking at different angles on this issue. I >> personally do think it's worth leaving this feature in the protocol >> specification as it is very useful to provide an alternative to nailing >> up (potentially) huge numbers of connections to the AAA server and >> enabling for other network infrastructure devices to perform >> assessments (as discussed below). >>=20 >> However, I do appreciate that implementers of some products may not >> wish to address these issues, so I think it makes sense for it to be an >> optional to implement feature (particularly on the client). >>=20 >>> -----Original Message----- >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>> Sent: Friday, May 18, 2012 1:03 AM >>> To: Paul Sangster >>> Cc: Stephen Hanna; nea@ietf.org >>> Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 >>>=20 >>>=20 >>> Hi Paul, >>>=20 >>> On question #1, I'm not sure we're talking about >>> quite the same issue. >>>=20 >>> My concern here isn't security related, its about the >>> complexity of allowing the NEA server to be the >>> TLS client. That causes the spec to be more complex >>> in a bunch of places, adds some work to both >>> implementations and adds complexity to deployments, >>> in that e.g. the NEA server TLS server cert now has >>> to also work as a TLS client cert if you want to >>> use this feature. >>>=20 >>> So my question is really whether the WG are sure >>> you want to keep this feature or not. If the answer >>> is "yes, we want to keep it" that's fine, I'll not >>> stop things moving ahead (I may have to hold my >>> nose a bit though;-). >>>=20 >>> S >>>=20 >>>=20 >>> On 05/17/2012 10:10 PM, Paul Sangster wrote: >>>> Stephen, >>>>=20 >>>> Thanks for all the great feedback, I suspect we would need to do a >>> revision to address everything. Let me respond to question 1 since >> its >>> mentioned as the primary concern. We've discussed the inbound NEA >>> Server initiated assessments a few times and hadn't ever planned to >>> remove it since it's such a useful feature. Clearly its use comes >> with >>> some risks that deployers need to account for with countermeasures. >>> Having that feature in the specification allows implementers and >>> deployers to use that feature in a standards based way and an >>> understanding of the risks. >>>>=20 >>>> Personally, I don't view the have every endpoint nail up the TCP >>> connection to the NEA Server for re-assessments as a great solution >> for >>> everyone (e.g. scaling issues, only usable by AAA server, ...). >>> Allowing customers particularly those with internal deployments >> inside >>> the enterprise edge firewalls to have network infrastructure devices >>> beside just the AAA server (e.g. compliance/conformance, patch >>> management or security management tools) to reach out to the desktops >>> and perform assessments when network security policies change or as >>> urgent patches are released is a nice feature to allow. >>>>=20 >>>> Endpoint agents could accept only IPsec or TLS protected >> connections >>> as a countermeasure against many forms of attack on the exposed >> ports. >>> Leaving the option in allows the deployer to decide what works best >>> with their deployment (scale, product mix, threat model and goals). >>>>=20 >>>> Paul >>>>=20 >>>>> -----Original Message----- >>>>> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf >>> Of >>>>> Stephen Farrell >>>>> Sent: Thursday, May 17, 2012 5:08 AM >>>>> To: Stephen Hanna >>>>> Cc: nea@ietf.org >>>>> Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 >>>>>=20 >>>>>=20 >>>>> Hi Steve, >>>>>=20 >>>>> My AD review of this is below. I think question 1 >>>>> is the main one where I have a concern really, the >>>>> others are mostly not-quite-nits or things where I'm >>>>> just asking, or where there'd be an easy fix if >>>>> a change is needed. >>>>>=20 >>>>> I dunno if this will require a revised I-D or not. >>>>> I suspect it will, but will wait for your/the WG's >>>>> response before putting it in that state. Please >>>>> do argue about that if, having seen this review, >>>>> you think this doesn't require another rev. >>>>>=20 >>>>> (And if some of my questions are just dumb, then >>>>> do say, I'm quite used to that:-) >>>>>=20 >>>>> Cheers, >>>>> S. >>>>>=20 >>>>> Questions: >>>>>=20 >>>>> (1) 3.1.1, This says in one place "the NEA Client is >>>>> effectively acting as a TLS server" which I thought was >>>>> going to be more strongly deprecated or entirely removed? >>>>> While you do recommend (RECOMMEND is good 2119 language >>>>> btw) not doing that, it won't work in many cases, so is it >>>>> really worth keeping at all? How about just leaving in the >>>>> first and last paragraphs of 3.1.1? (Would need some more >>>>> edits to fix up, but all of those would simplify the >>>>> document overall.) >>>>>=20 >>>>> (2) 3.3, last sentence: this says "an attack" - is this >>>>> normative instruction meant to apply only for detected >>>>> Asokan attacks, or does it also apply for any other attack >>>>> at all, or for some others? For example, what if the TLS >>>>> handshake terminates fails for some reason not specifically >>>>> stated in this document? What if some new unexpected attack >>>>> on NEA is discovered - would this MUST apply to that? I >>>>> guess choices are to s/an attack/this attack/ if you just >>>>> want this to cover the Asokan attack, or if a more general >>>>> statement is desirable then maybe adding something >>>>> somewhere else would be right. >>>>>=20 >>>>> (3) 3.4.2: How do I know that the "TLS Setup" phase has >>>>> completed and how do I enforce the requirement that TLS >>>>> re-negotiation MUST NOT happen after that? The former seems >>>>> unclear unless it means "after the Finished exchanges" in >>>>> which case maybe say so. The latter seems tricky - will >>>>> current TLS implementations allow you to enforce that? >>>>>=20 >>>>> (4) 3.4.1.1: You do validation according to 5280 which is >>>>> fine. But in 5280, revocation checking is optional. Do you >>>>> need to check revocation here? If you do, then do you need >>>>> to say that the NEA client might need to contact an OCSP >>>>> responder, or is some further profiling of how TLS and 5280 >>>>> are used needed? (e.g. OCSP stapling?) There are a bunch >>>>> of reasonable answers possible and I'm fine with any of 'em >>>>> (particularly whatever folks will implement:-) but I >>>>> suspect you may need to say a bit more here. >>>>>=20 >>>>> (5) 3.4.2.3 - The last sentence is a bit confusing - what >>>>> should happen if a "NEA protocol" may not be able to make >>>>> use of full-duplex? (And maybe s/protocol/implementation/?) >>>>> What do you do if you're one of those or talking to one of >>>>> those? >>>>>=20 >>>>> (6) 3.5: I don't think that enterprise numbers [1] are >>>>> restricted to 24 bits - those are OID arcs which are in >>>>> theory unlimited length. What happens if one is larger than >>>>> 24bits? Reserving a number from that registry also probably >>>>> needs an IANA action, and who knows that might conflict >>>>> with something else. I know you set this to zero but I'm >>>>> guessing vendors will use this as well or its used >>>>> elsewhere by NEA so I do wonder. This also affects 3.9. >>>>> (Nits on this as well: That might also be better stated as >>>>> "Implementations of this specification MUST..." just for >>>>> clarity. And it'd be good to put in a link or reference to >>>>> the IANA registry somewhere - not everyone knows what that >>>>> registry is I guess. Also, referring to 0 as an IETF SMI >>>>> Private Entreprise Number might raise a hackle, since >>>>> that's reserved in the IANA registry. Having said all that, >>>>> if you got this past in other NEA RFCs (didn't check) then >>>>> doing the same thing here is probably ok.) >>>>>=20 >>>>> [1] http://www.iana.org/assignments/enterprise-numbers >>>>>=20 >>>>> (7) 3.5, Message Type. I don't understand what "MUST >>>>> interoperate with other parties despite any differences" >>>>> means here and suspect that that 2119 MUST isn't doable. >>>>>=20 >>>>> (8) 3.5, 6.2 Any "reserved" values should really be >>>>> mentioned in the IANA considerations section so IANA don't >>>>> go and give them out, I mean the 0xffff... ones. "9+" is >>>>> also a bit odd in 6.2. You might want to change that to >>>>> specify the exact range "available for allocation by DE" >>>>> (or whatever is the right term) different from the >>>>> "reserved" value(s) there. >>>>>=20 >>>>> (9) 3.6, is it really ok for the "TLS session initiator" to >>>>> always be the one who proposes the versions in the version >>>>> request message? You still allow the NEA server to be the >>>>> TLS session initiator so what'd happen with this then is >>>>> confusing - the naughty client could get to pick the >>>>> weakest version of PT-TLS that the server supports? 3.7 >>>>> also seems to contradict this, saying that the "PT-TLS >>>>> initiator" sends the version request. Maybe there is some >>>>> cleaning up needed here? >>>>>=20 >>>>> (10) 4.1, are you saying here that if any of these trust >>>>> relationships do not hold, then PT-TLS ought not be used? >>>>> If so, then saying that explicitly would be good. For >>>>> example, it could be that with some implementations, e.g. >>>>> that use less secure inter-proces communications, a bad >>>>> process on a client could invalidate some of these >>>>> assumptions, thus (maybe) making PT-TLS unsafe. >>>>>=20 >>>>> (11) section 5: do you mean the NEA client SHOULD (in 2119 >>>>> terms) provide an indication here? If not, why not? If so, >>>>> what's the criteria for not providing that? (Perhaps if >>>>> there is no UI?) Same should/SHOULD question for the last >>>>> paragraph, i.e. s/should ensure/SHOULD ensure/ and what's >>>>> the exception? >>>>>=20 >>>>> (12) section 6: some of the intro text here is not really >>>>> for IANA, should it be moved elsewhere? (Mainly the >>>>> explanation of PEN handling, which might go up into 3.5 >>>>> perhaps?) >>>>>=20 >>>>> (13) section 6.1: you're asking IANA to act as a repository >>>>> for non-RFC specifications (sort-of), I think that's maybe >>>>> an innovation (not sure) that should be checked out with >>>>> IANA, or maybe you've done that or know of a precedent? >>>>>=20 >>>>> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that >>>>> entries with PEN value 0 need to be IETF stream RFCs, >>>>> or standards-track RFCs, or just RFCs or what? If you >>>>> want the DE to be able to add PEN=3D0 entries without >>>>> an RFC, I think saying that would be best. >>>>>=20 >>>>> (15) References: can we not make the reference to 4346 (TLS >>>>> 1.1) informative and craft language to make that work? E.g. >>>>> say you SHOULD support TLS1.2 but that in reality a lot of >>>>> people still don't and are only doing 4346 as of now? I >>>>> think if you do that you can argue that TLS 1.1 is not >>>>> a normative reference and that'd be better in future once >>>>> most everyone has caught up with TLS1.2. >>>>>=20 >>>>> Nits: >>>>>=20 >>>>> - 1.4: Not sure its right to talk about the future actions >>>>> of some other organisation in such a definite manner. >>>>> Might be better to say that "the authors understand >>>>> that..." or some other weasel words, or even better would >>>>> be to refer to something the TCG have published if that's >>>>> possible. >>>>>=20 >>>>> - s2, 1st para: maybe s/should use/can use/ just to avoid >>>>> rfc 2119 confusion. >>>>>=20 >>>>> - 2.1, why use the "underlying carrier protocol" when only >>>>> TCP is covered here? >>>>>=20 >>>>> - 2.4, I'm not clear why this section is (still) needed. >>>>> It tries to say, but I don't get it. Did you once want to >>>>> control what ciphersuites could be used by TLS as part of >>>>> NEA? No problem with it staying though. >>>>>=20 >>>>> - 3.1.2, last sentence, s/must/MUST/? or s/must/needs to >>>>> be/? >>>>>=20 >>>>> - 3.4.2, s/normally starts/starts/ how else can it work? >>>>> Also not quite correct to say the connection triggers TLS >>>>> h/s - the sending/listening processes do that. >>>>>=20 >>>>> - 3.4.2.2: The end of this phase is also a little >>>>> ambiguous. You say we're done when the NEA server has sent >>>>> an empty list of sasl mechanisms after all NEA client >>>>> authentications are done. But then you also say that the >>>>> NEA server can choose to not authenticate the client and >>>>> move on. But how would the client know that the PT-TLS >>>>> negotiation phase is over in that case? Ah, 3.8.3 clears >>>>> this up. Might be worth clarifying that a bit in 3.4.2.2. >>>>>=20 >>>>> - 3.5, Message Id. Since receivers have to handle roll >>>>> over, there doesn't seem to be a need for a MUST start at >>>>> zero, is there? And maybe you don't even really need the >>>>> MUST monotonically increasing either? (Aside: I generally >>>>> prefer if senders can start randomly anyway, just in case >>>>> there's some message guessing threat - never any harm to >>>>> make that harder IMO.) >>>>>=20 >>>>> - 3.5, message length: your answer here is probably "no," >>>>> which is fine, but I wondered if there's any useful >>>>> guidance about over-long messages that could be given? E.g. >>>>> could a NEA client try send a (number of) 2^31 byte >>>>> payload(s) to DoS the server in the hope that the server >>>>> would then fail-open? (I note that the TLS plaintext max >>>>> is 2^14 bytes in one record, dunno if that might be a >>>>> factor here or not to be honest.) >>>>>=20 >>>>> - 3.6, seems off for a standards track RFC to distinguish >>>>> between production code and something else, maybe that >>>>> could be better phrased? >>>>>=20 >>>>> - 3.6, PB-TNC batch: total and utter nit:-) The reference >>>>> to section 4 of the PB-TNC spec is rendered with the wrong >>>>> URL in the tools.ietf.org version of the draft. >>>>> (Interpreted as a link to section 4 of this.) I think if >>>>> you added the RFC number for PB-TNC it might help there. >>>>>=20 >>>>> - 3.8, 2nd last para, maybe s/may require/MAY require/ ? >>>>>=20 >>>>> - 3.8.5.4, maybe s/may trigger/MAY trigger/ ? >>>>>=20 >>>>> - section 6, s/requests the IANA/requests that IANA/? >>>>>=20 >>>>> - 6.2, "Once this document becomes an RFC..." probably >>>>> ought be deleted. Easier if that's a separate paragraph >>>>> with an instruction to the RFC editor as to what to delete, >>>>> which is not all of the paragraph in this case I think. >>>>>=20 >>>>> _______________________________________________ >>>>> Nea mailing list >>>>> Nea@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nea >>>>=20 >>>>=20 >>>>=20 >>>>=20 From Paul_Sangster@symantec.com Fri May 25 19:12:01 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C0C11E8087 for ; Fri, 25 May 2012 19:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, 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 KlBbnuKyrcA3 for ; Fri, 25 May 2012 19:11:59 -0700 (PDT) Received: from tus1smtoutpex02.symantec.com (tus1smtoutpex02.symantec.com [216.10.195.242]) by ietfa.amsl.com (Postfix) with ESMTP id 84F6811E807F for ; Fri, 25 May 2012 19:11:59 -0700 (PDT) X-AuditID: d80ac3f2-b7fa16d000004536-00-4fc03bde422f Received: from ecl1mtahubpin02.ges.symantec.com (ECL1MTAHUBPIN02.ges.symantec.com [10.48.69.202]) by tus1smtoutpex02.symantec.com (Symantec Brightmail Gateway out) with SMTP id 32.50.17718.EDB30CF4; Sat, 26 May 2012 02:11:43 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by ecl1mtahubpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1SY6Tm-0004gz-2W; Sat, 26 May 2012 02:11:42 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([169.254.188.134]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([172.24.185.246]) with mapi; Fri, 25 May 2012 19:11:41 -0700 From: Paul Sangster To: Stephen Farrell , Stephen Hanna Date: Fri, 25 May 2012 19:12:33 -0700 Thread-Topic: [Nea] AD review of draft-ietf-nea-pt-tls-04 Thread-Index: Ac04Uv/+rHbNWPDKRyymq2Aqk6orAgCkeJdw Message-ID: <6E79D623502C70419A9EAB18E4D274252B8861BF64@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4FB4EA34.2020104@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B881C825E@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FB60226.1010202@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B881C8705@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> 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+NgFlrOIsWRmVeSWpSXmKPExsXCZeB6Sve+9QF/gyXb1Cw+v62weHzuFLPF 9L3X2B2YPdZ2X2XzWLLkJ5PH9aar7AHMUVw2Kak5mWWpRfp2CVwZdxc/ZCw40sdYsb/tGHsD 45uCLkZODgkBE4kv3YfZIGwxiQv31gPZXBxCAu8YJV63tTFDOK8ZJQ7NmASVWc0oMenwP7AW NgEDiZ1HTrGD2CICoRJLN25hBLGZBRQlprcuZQKxWQRUJQ5+6WQFsYUFLCRuLVjMCFFvKXHk 0ieWLkYOINtIYsuCapAwr0CUxNvF31ghdi1glvj04gALSIJTwFZi/alZYDMZgU79fmoNE8Qu cYlbT+YzQbwgILFkz3lmCFtU4uXjf6wQ9aISd9rXQ92mI7Fg9yc2CFtbYtnC18wQiwUlTs58 wjKBUXwWkrGzkLTMQtIyC0nLAkaWVYwyJaXFhsW5JfmlJQWpFQZGesWVuYnAyEvWS87P3cQI jL4bXIc/7WC8sVTxEKMAB6MSD+88wwP+QqyJZUCVhxglOJiVRHidLYFCvCmJlVWpRfnxRaU5 qcWHGKU5WJTEeT/s3uovJJCeWJKanZpakFoEk2Xi4JRqYGwLYC4/EV70pHB+WejJ6056zYHm 76d5Cru/vWPyhz1q2wPWOJvHh2J+SS6KkAh4+tn5bAz/yuNJb1yNroa+LFGtmbBDrG+2gnJm 6g12o8d2+a8O6z1a9XjqF71Z0ibP91WVG+zpm7ZKvlb/n3v83ltahTVeMayLA6Z9PPnpaFxT l3brMy6h1UosxRmJhlrMRcWJAHOiFrO6AgAA Cc: "nea@ietf.org" Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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, 26 May 2012 02:12:01 -0000 Yes, I think it's worth doing an update before advancing the document to th= e IESG. I'll respond to your comments to get the ball rolling. > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, May 22, 2012 12:42 PM > To: Stephen Hanna > Cc: Paul Sangster; nea@ietf.org > Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 > > That's fine Steve, like I said I wanted to check. > > Can you get back to me as to whether any of the other questions warrant > a revised I-D? > > Cheers, > S > > On 22 May 2012, at 20:25, Stephen Hanna wrote: > > > Stephen Farrell wrote: > >> So my question is really whether the WG are sure > >> you want to keep this feature or not. > > > > While server-initiated PT-TLS sessions are not my favorite > > part of PT-TLS, this feature is clearly required by the use > > cases in RFC 5209 (NEA Overview and Requirements). Section > > 6.2.2 of that spec describes several situations where the > > NEA Server may need to initiate a reassessment: periodic, > > event-based, and in response to policy updates. One way to > > do this is to require each endpoint to always maintain a TLS > > connection to a NEA Server. But this is a lot of overhead so > > section 6.2.2.2 of RFC 5209 describes an approach where the > > NEA Server reaches out to NEA Clients as needed. > > > > This use case was agreed to by the NEA WG and the IETF and the > > IESG more than four years ago. Clearly, it represented rough > > consensus at the time. Since then, we've spent a good deal of > > WG time creating this spec to meet the use case, including > > changes just a few months ago to describe in more detail how > > certificates should be handled for this case. The WG is well > > aware of the ugliness involved. > > > > Therefore, I conclude that we still have rough WG consensus in > > favor of keeping server-initiated sessions as an optional > > feature. Stephen, please let me know if you want me to run a > > formal consensus check to verify this. > > > > And thanks for all your careful review. This is a good issue > > to raise. It's the least elegant part of the protocol and should > > only be included if there's a driving reason to do so and a > > strong WG consensus that we should include it. But I believe > > based on what I've seen that we have both the reason and the > > consensus. > > > > Thanks, > > > > Steve > > > >> -----Original Message----- > >> From: Paul Sangster [mailto:Paul_Sangster@symantec.com] > >> Sent: Friday, May 18, 2012 12:47 PM > >> To: Stephen Farrell > >> Cc: Stephen Hanna; nea@ietf.org > >> Subject: RE: [Nea] AD review of draft-ietf-nea-pt-tls-04 > >> > >> Thanks, I agree we were looking at different angles on this issue. > I > >> personally do think it's worth leaving this feature in the protocol > >> specification as it is very useful to provide an alternative to > nailing > >> up (potentially) huge numbers of connections to the AAA server and > >> enabling for other network infrastructure devices to perform > >> assessments (as discussed below). > >> > >> However, I do appreciate that implementers of some products may not > >> wish to address these issues, so I think it makes sense for it to be > an > >> optional to implement feature (particularly on the client). > >> > >>> -----Original Message----- > >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > >>> Sent: Friday, May 18, 2012 1:03 AM > >>> To: Paul Sangster > >>> Cc: Stephen Hanna; nea@ietf.org > >>> Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 > >>> > >>> > >>> Hi Paul, > >>> > >>> On question #1, I'm not sure we're talking about > >>> quite the same issue. > >>> > >>> My concern here isn't security related, its about the > >>> complexity of allowing the NEA server to be the > >>> TLS client. That causes the spec to be more complex > >>> in a bunch of places, adds some work to both > >>> implementations and adds complexity to deployments, > >>> in that e.g. the NEA server TLS server cert now has > >>> to also work as a TLS client cert if you want to > >>> use this feature. > >>> > >>> So my question is really whether the WG are sure > >>> you want to keep this feature or not. If the answer > >>> is "yes, we want to keep it" that's fine, I'll not > >>> stop things moving ahead (I may have to hold my > >>> nose a bit though;-). > >>> > >>> S > >>> > >>> > >>> On 05/17/2012 10:10 PM, Paul Sangster wrote: > >>>> Stephen, > >>>> > >>>> Thanks for all the great feedback, I suspect we would need to do a > >>> revision to address everything. Let me respond to question 1 since > >> its > >>> mentioned as the primary concern. We've discussed the inbound NEA > >>> Server initiated assessments a few times and hadn't ever planned to > >>> remove it since it's such a useful feature. Clearly its use comes > >> with > >>> some risks that deployers need to account for with countermeasures. > >>> Having that feature in the specification allows implementers and > >>> deployers to use that feature in a standards based way and an > >>> understanding of the risks. > >>>> > >>>> Personally, I don't view the have every endpoint nail up the TCP > >>> connection to the NEA Server for re-assessments as a great solution > >> for > >>> everyone (e.g. scaling issues, only usable by AAA server, ...). > >>> Allowing customers particularly those with internal deployments > >> inside > >>> the enterprise edge firewalls to have network infrastructure > devices > >>> beside just the AAA server (e.g. compliance/conformance, patch > >>> management or security management tools) to reach out to the > desktops > >>> and perform assessments when network security policies change or as > >>> urgent patches are released is a nice feature to allow. > >>>> > >>>> Endpoint agents could accept only IPsec or TLS protected > >> connections > >>> as a countermeasure against many forms of attack on the exposed > >> ports. > >>> Leaving the option in allows the deployer to decide what works best > >>> with their deployment (scale, product mix, threat model and goals). > >>>> > >>>> Paul > >>>> > >>>>> -----Original Message----- > >>>>> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On > Behalf > >>> Of > >>>>> Stephen Farrell > >>>>> Sent: Thursday, May 17, 2012 5:08 AM > >>>>> To: Stephen Hanna > >>>>> Cc: nea@ietf.org > >>>>> Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 > >>>>> > >>>>> > >>>>> Hi Steve, > >>>>> > >>>>> My AD review of this is below. I think question 1 > >>>>> is the main one where I have a concern really, the > >>>>> others are mostly not-quite-nits or things where I'm > >>>>> just asking, or where there'd be an easy fix if > >>>>> a change is needed. > >>>>> > >>>>> I dunno if this will require a revised I-D or not. > >>>>> I suspect it will, but will wait for your/the WG's > >>>>> response before putting it in that state. Please > >>>>> do argue about that if, having seen this review, > >>>>> you think this doesn't require another rev. > >>>>> > >>>>> (And if some of my questions are just dumb, then > >>>>> do say, I'm quite used to that:-) > >>>>> > >>>>> Cheers, > >>>>> S. > >>>>> > >>>>> Questions: > >>>>> > >>>>> (1) 3.1.1, This says in one place "the NEA Client is > >>>>> effectively acting as a TLS server" which I thought was > >>>>> going to be more strongly deprecated or entirely removed? > >>>>> While you do recommend (RECOMMEND is good 2119 language > >>>>> btw) not doing that, it won't work in many cases, so is it > >>>>> really worth keeping at all? How about just leaving in the > >>>>> first and last paragraphs of 3.1.1? (Would need some more > >>>>> edits to fix up, but all of those would simplify the > >>>>> document overall.) > >>>>> > >>>>> (2) 3.3, last sentence: this says "an attack" - is this > >>>>> normative instruction meant to apply only for detected > >>>>> Asokan attacks, or does it also apply for any other attack > >>>>> at all, or for some others? For example, what if the TLS > >>>>> handshake terminates fails for some reason not specifically > >>>>> stated in this document? What if some new unexpected attack > >>>>> on NEA is discovered - would this MUST apply to that? I > >>>>> guess choices are to s/an attack/this attack/ if you just > >>>>> want this to cover the Asokan attack, or if a more general > >>>>> statement is desirable then maybe adding something > >>>>> somewhere else would be right. > >>>>> > >>>>> (3) 3.4.2: How do I know that the "TLS Setup" phase has > >>>>> completed and how do I enforce the requirement that TLS > >>>>> re-negotiation MUST NOT happen after that? The former seems > >>>>> unclear unless it means "after the Finished exchanges" in > >>>>> which case maybe say so. The latter seems tricky - will > >>>>> current TLS implementations allow you to enforce that? > >>>>> > >>>>> (4) 3.4.1.1: You do validation according to 5280 which is > >>>>> fine. But in 5280, revocation checking is optional. Do you > >>>>> need to check revocation here? If you do, then do you need > >>>>> to say that the NEA client might need to contact an OCSP > >>>>> responder, or is some further profiling of how TLS and 5280 > >>>>> are used needed? (e.g. OCSP stapling?) There are a bunch > >>>>> of reasonable answers possible and I'm fine with any of 'em > >>>>> (particularly whatever folks will implement:-) but I > >>>>> suspect you may need to say a bit more here. > >>>>> > >>>>> (5) 3.4.2.3 - The last sentence is a bit confusing - what > >>>>> should happen if a "NEA protocol" may not be able to make > >>>>> use of full-duplex? (And maybe s/protocol/implementation/?) > >>>>> What do you do if you're one of those or talking to one of > >>>>> those? > >>>>> > >>>>> (6) 3.5: I don't think that enterprise numbers [1] are > >>>>> restricted to 24 bits - those are OID arcs which are in > >>>>> theory unlimited length. What happens if one is larger than > >>>>> 24bits? Reserving a number from that registry also probably > >>>>> needs an IANA action, and who knows that might conflict > >>>>> with something else. I know you set this to zero but I'm > >>>>> guessing vendors will use this as well or its used > >>>>> elsewhere by NEA so I do wonder. This also affects 3.9. > >>>>> (Nits on this as well: That might also be better stated as > >>>>> "Implementations of this specification MUST..." just for > >>>>> clarity. And it'd be good to put in a link or reference to > >>>>> the IANA registry somewhere - not everyone knows what that > >>>>> registry is I guess. Also, referring to 0 as an IETF SMI > >>>>> Private Entreprise Number might raise a hackle, since > >>>>> that's reserved in the IANA registry. Having said all that, > >>>>> if you got this past in other NEA RFCs (didn't check) then > >>>>> doing the same thing here is probably ok.) > >>>>> > >>>>> [1] http://www.iana.org/assignments/enterprise-numbers > >>>>> > >>>>> (7) 3.5, Message Type. I don't understand what "MUST > >>>>> interoperate with other parties despite any differences" > >>>>> means here and suspect that that 2119 MUST isn't doable. > >>>>> > >>>>> (8) 3.5, 6.2 Any "reserved" values should really be > >>>>> mentioned in the IANA considerations section so IANA don't > >>>>> go and give them out, I mean the 0xffff... ones. "9+" is > >>>>> also a bit odd in 6.2. You might want to change that to > >>>>> specify the exact range "available for allocation by DE" > >>>>> (or whatever is the right term) different from the > >>>>> "reserved" value(s) there. > >>>>> > >>>>> (9) 3.6, is it really ok for the "TLS session initiator" to > >>>>> always be the one who proposes the versions in the version > >>>>> request message? You still allow the NEA server to be the > >>>>> TLS session initiator so what'd happen with this then is > >>>>> confusing - the naughty client could get to pick the > >>>>> weakest version of PT-TLS that the server supports? 3.7 > >>>>> also seems to contradict this, saying that the "PT-TLS > >>>>> initiator" sends the version request. Maybe there is some > >>>>> cleaning up needed here? > >>>>> > >>>>> (10) 4.1, are you saying here that if any of these trust > >>>>> relationships do not hold, then PT-TLS ought not be used? > >>>>> If so, then saying that explicitly would be good. For > >>>>> example, it could be that with some implementations, e.g. > >>>>> that use less secure inter-proces communications, a bad > >>>>> process on a client could invalidate some of these > >>>>> assumptions, thus (maybe) making PT-TLS unsafe. > >>>>> > >>>>> (11) section 5: do you mean the NEA client SHOULD (in 2119 > >>>>> terms) provide an indication here? If not, why not? If so, > >>>>> what's the criteria for not providing that? (Perhaps if > >>>>> there is no UI?) Same should/SHOULD question for the last > >>>>> paragraph, i.e. s/should ensure/SHOULD ensure/ and what's > >>>>> the exception? > >>>>> > >>>>> (12) section 6: some of the intro text here is not really > >>>>> for IANA, should it be moved elsewhere? (Mainly the > >>>>> explanation of PEN handling, which might go up into 3.5 > >>>>> perhaps?) > >>>>> > >>>>> (13) section 6.1: you're asking IANA to act as a repository > >>>>> for non-RFC specifications (sort-of), I think that's maybe > >>>>> an innovation (not sure) that should be checked out with > >>>>> IANA, or maybe you've done that or know of a precedent? > >>>>> > >>>>> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that > >>>>> entries with PEN value 0 need to be IETF stream RFCs, > >>>>> or standards-track RFCs, or just RFCs or what? If you > >>>>> want the DE to be able to add PEN=3D0 entries without > >>>>> an RFC, I think saying that would be best. > >>>>> > >>>>> (15) References: can we not make the reference to 4346 (TLS > >>>>> 1.1) informative and craft language to make that work? E.g. > >>>>> say you SHOULD support TLS1.2 but that in reality a lot of > >>>>> people still don't and are only doing 4346 as of now? I > >>>>> think if you do that you can argue that TLS 1.1 is not > >>>>> a normative reference and that'd be better in future once > >>>>> most everyone has caught up with TLS1.2. > >>>>> > >>>>> Nits: > >>>>> > >>>>> - 1.4: Not sure its right to talk about the future actions > >>>>> of some other organisation in such a definite manner. > >>>>> Might be better to say that "the authors understand > >>>>> that..." or some other weasel words, or even better would > >>>>> be to refer to something the TCG have published if that's > >>>>> possible. > >>>>> > >>>>> - s2, 1st para: maybe s/should use/can use/ just to avoid > >>>>> rfc 2119 confusion. > >>>>> > >>>>> - 2.1, why use the "underlying carrier protocol" when only > >>>>> TCP is covered here? > >>>>> > >>>>> - 2.4, I'm not clear why this section is (still) needed. > >>>>> It tries to say, but I don't get it. Did you once want to > >>>>> control what ciphersuites could be used by TLS as part of > >>>>> NEA? No problem with it staying though. > >>>>> > >>>>> - 3.1.2, last sentence, s/must/MUST/? or s/must/needs to > >>>>> be/? > >>>>> > >>>>> - 3.4.2, s/normally starts/starts/ how else can it work? > >>>>> Also not quite correct to say the connection triggers TLS > >>>>> h/s - the sending/listening processes do that. > >>>>> > >>>>> - 3.4.2.2: The end of this phase is also a little > >>>>> ambiguous. You say we're done when the NEA server has sent > >>>>> an empty list of sasl mechanisms after all NEA client > >>>>> authentications are done. But then you also say that the > >>>>> NEA server can choose to not authenticate the client and > >>>>> move on. But how would the client know that the PT-TLS > >>>>> negotiation phase is over in that case? Ah, 3.8.3 clears > >>>>> this up. Might be worth clarifying that a bit in 3.4.2.2. > >>>>> > >>>>> - 3.5, Message Id. Since receivers have to handle roll > >>>>> over, there doesn't seem to be a need for a MUST start at > >>>>> zero, is there? And maybe you don't even really need the > >>>>> MUST monotonically increasing either? (Aside: I generally > >>>>> prefer if senders can start randomly anyway, just in case > >>>>> there's some message guessing threat - never any harm to > >>>>> make that harder IMO.) > >>>>> > >>>>> - 3.5, message length: your answer here is probably "no," > >>>>> which is fine, but I wondered if there's any useful > >>>>> guidance about over-long messages that could be given? E.g. > >>>>> could a NEA client try send a (number of) 2^31 byte > >>>>> payload(s) to DoS the server in the hope that the server > >>>>> would then fail-open? (I note that the TLS plaintext max > >>>>> is 2^14 bytes in one record, dunno if that might be a > >>>>> factor here or not to be honest.) > >>>>> > >>>>> - 3.6, seems off for a standards track RFC to distinguish > >>>>> between production code and something else, maybe that > >>>>> could be better phrased? > >>>>> > >>>>> - 3.6, PB-TNC batch: total and utter nit:-) The reference > >>>>> to section 4 of the PB-TNC spec is rendered with the wrong > >>>>> URL in the tools.ietf.org version of the draft. > >>>>> (Interpreted as a link to section 4 of this.) I think if > >>>>> you added the RFC number for PB-TNC it might help there. > >>>>> > >>>>> - 3.8, 2nd last para, maybe s/may require/MAY require/ ? > >>>>> > >>>>> - 3.8.5.4, maybe s/may trigger/MAY trigger/ ? > >>>>> > >>>>> - section 6, s/requests the IANA/requests that IANA/? > >>>>> > >>>>> - 6.2, "Once this document becomes an RFC..." probably > >>>>> ought be deleted. Easier if that's a separate paragraph > >>>>> with an instruction to the RFC editor as to what to delete, > >>>>> which is not all of the paragraph in this case I think. > >>>>> > >>>>> _______________________________________________ > >>>>> Nea mailing list > >>>>> Nea@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/nea > >>>> > >>>> > >>>> > >>>> From Paul_Sangster@symantec.com Fri May 25 19:44:13 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12E621F8844 for ; Fri, 25 May 2012 19:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=1.950, BAYES_00=-2.599, 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 JJ7y8sNdHch7 for ; Fri, 25 May 2012 19:44:12 -0700 (PDT) Received: from ecl1mtaoutpex02.symantec.com (ecl1mtaoutpex02.symantec.com [166.98.1.210]) by ietfa.amsl.com (Postfix) with ESMTP id 9307821F8842 for ; Fri, 25 May 2012 19:44:12 -0700 (PDT) X-AuditID: a66201d2-b7fbf6d000001ef9-5b-4fc0437aa448 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) by ecl1mtaoutpex02.symantec.com (Symantec Messaging Gateway) with SMTP id E0.E0.07929.B7340CF4; Sat, 26 May 2012 02:44:11 +0000 (GMT) Received: from [155.64.220.138] (helo=TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1SY6zC-0005iY-NS; Sat, 26 May 2012 02:44:10 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([169.254.188.134]) by TUS1XCHHUBPIN02.SYMC.SYMANTEC.COM ([172.24.185.246]) with mapi; Fri, 25 May 2012 19:44:10 -0700 From: Paul Sangster To: Stephen Farrell Date: Fri, 25 May 2012 19:45:09 -0700 Thread-Topic: [Nea] AD review of draft-ietf-nea-pt-tls-04 Thread-Index: Ac00JcplI3cv5ZHDR9SCk1FDpiDZ9AGv9kvg Message-ID: <6E79D623502C70419A9EAB18E4D274252B8861BF65@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4FB4EA34.2020104@cs.tcd.ie> In-Reply-To: <4FB4EA34.2020104@cs.tcd.ie> 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+NgFprNIsWRmVeSWpSXmKPExsVyYMU1Hd1q5wP+Bqu+ilt8flthMX3vNXYH Jo+13VfZPJYs+ckUwBTFZZOSmpNZllqkb5fAlbF8Vh9Twc6gis6tOg2Msxy7GDk5JARMJN7t P8ACYYtJXLi3nq2LkYtDSOA1o8SFaX+Y4ZyWtf2sEM5qRolZmzuYQFrYBAwkdh45xQ5iiwjo S+zdfA7MZhZQlJjeuhSshkVAVeLEjOVsILawgIXErQWLGSHqLSWOXPrEAmEbSdzcPZ0VxOYV iJL4s74XrF5IIEti5YUDYHM4BTQletauAoszAp36/dQaJohd4hK3nsxngnhBQGLJnvPMELao xMvH/1gh6kUl7rSvZ4So15FYsPsTG4StLbFs4WtmiL2CEidnPmGZwCg+C8nYWUhaZiFpmYWk ZQEjyypGmdTkHMPcksT80pKC1AoDI73iytxEYIQl6yXn525iBEbZsiTGSzsY7x/WPcQowMGo xMPbY3/AX4g1sQyo8hCjBAezkgivsyVQiDclsbIqtSg/vqg0J7X4EKM0B4uSOO+FXVv9hQTS E0tSs1NTC1KLYLJMHJxSDYxNU+f07itwSpPauu1XYtWa+ZVZTJkHVzR8/XrD8zT/gXbxcLG5 fyoSJ+/mat877961CrHaeK/7889+2eypyGCctuZjZ3m2ecKZW4onDMrfbDvArXFW1aX5wPEz zC/eHbnpXCv09Mv3Uu7cd54Bvk4pwqm97tqm1cVRb3O5i7/cnjrRtqFcXleJpTgj0VCLuag4 EQAsr8FZrgIAAA== Cc: "nea@ietf.org" Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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, 26 May 2012 02:44:14 -0000 Thanks for the detailed review of the document, some comments are in-lined = below for the non-nits: > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of > Stephen Farrell > Sent: Thursday, May 17, 2012 5:08 AM > To: Stephen Hanna > Cc: nea@ietf.org > Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 >=20 >=20 > Hi Steve, >=20 > My AD review of this is below. I think question 1 > is the main one where I have a concern really, the > others are mostly not-quite-nits or things where I'm > just asking, or where there'd be an easy fix if > a change is needed. >=20 > I dunno if this will require a revised I-D or not. > I suspect it will, but will wait for your/the WG's > response before putting it in that state. Please > do argue about that if, having seen this review, > you think this doesn't require another rev. >=20 > (And if some of my questions are just dumb, then > do say, I'm quite used to that:-) >=20 > Cheers, > S. >=20 > Questions: >=20 > (1) 3.1.1, This says in one place "the NEA Client is > effectively acting as a TLS server" which I thought was > going to be more strongly deprecated or entirely removed? > While you do recommend (RECOMMEND is good 2119 language > btw) not doing that, it won't work in many cases, so is it > really worth keeping at all? How about just leaving in the > first and last paragraphs of 3.1.1? (Would need some more > edits to fix up, but all of those would simplify the > document overall.) [PS:] We already discussed this one >=20 > (2) 3.3, last sentence: this says "an attack" - is this > normative instruction meant to apply only for detected > Asokan attacks, or does it also apply for any other attack > at all, or for some others? For example, what if the TLS > handshake terminates fails for some reason not specifically > stated in this document? What if some new unexpected attack > on NEA is discovered - would this MUST apply to that? I > guess choices are to s/an attack/this attack/ if you just > want this to cover the Asokan attack, or if a more general > statement is desirable then maybe adding something > somewhere else would be right. [PS:] Agreed, this was about the Asokan attack so will make that more clear= . >=20 > (3) 3.4.2: How do I know that the "TLS Setup" phase has > completed and how do I enforce the requirement that TLS > re-negotiation MUST NOT happen after that? The former seems > unclear unless it means "after the Finished exchanges" in > which case maybe say so. The latter seems tricky - will > current TLS implementations allow you to enforce that? [PS:] Will clarity its after the Finished messages. Yes we know of several= implementations allowing the renegotiation to be disabled. >=20 > (4) 3.4.1.1: You do validation according to 5280 which is > fine. But in 5280, revocation checking is optional. Do you > need to check revocation here? If you do, then do you need > to say that the NEA client might need to contact an OCSP > responder, or is some further profiling of how TLS and 5280 > are used needed? (e.g. OCSP stapling?) There are a bunch > of reasonable answers possible and I'm fine with any of 'em > (particularly whatever folks will implement:-) but I > suspect you may need to say a bit more here. [PS:] Will mention that the NEA Client can optionally do revocation checkin= g. >=20 > (5) 3.4.2.3 - The last sentence is a bit confusing - what > should happen if a "NEA protocol" may not be able to make > use of full-duplex? (And maybe s/protocol/implementation/?) > What do you do if you're one of those or talking to one of > those? [PS:] Its referring to the higher level protocols on top of PT that might n= ot support full-duplex (e.g. PB). So we'll make that more clear. >=20 > (6) 3.5: I don't think that enterprise numbers [1] are > restricted to 24 bits - those are OID arcs which are in > theory unlimited length. What happens if one is larger than > 24bits? Reserving a number from that registry also probably > needs an IANA action, and who knows that might conflict > with something else. I know you set this to zero but I'm > guessing vendors will use this as well or its used > elsewhere by NEA so I do wonder. This also affects 3.9. > (Nits on this as well: That might also be better stated as > "Implementations of this specification MUST..." just for > clarity. And it'd be good to put in a link or reference to > the IANA registry somewhere - not everyone knows what that > registry is I guess. Also, referring to 0 as an IETF SMI > Private Entreprise Number might raise a hackle, since > that's reserved in the IANA registry. Having said all that, > if you got this past in other NEA RFCs (didn't check) then > doing the same thing here is probably ok.) >=20 > [1] http://www.iana.org/assignments/enterprise-numbers [PS:] This approach is what we used in NEA's PA and PB protocols, so we're = just staying consistent with that approach in PT-TLS. So far the IANA has = only assigned 16 bits worth of PEN so we should have ALONG time before we w= ill exceed the 24 bits assuming a nearly sequential assignment of numbers. >=20 > (7) 3.5, Message Type. I don't understand what "MUST > interoperate with other parties despite any differences" > means here and suspect that that 2119 MUST isn't doable. [PS:] Will reword these sentences. This is about disallowing implementatio= ns to not interoperate with NEA complaints implements since they always req= uire a vendor specific attribute to be used to do an assessment. >=20 > (8) 3.5, 6.2 Any "reserved" values should really be > mentioned in the IANA considerations section so IANA don't > go and give them out, I mean the 0xffff... ones. "9+" is > also a bit odd in 6.2. You might want to change that to > specify the exact range "available for allocation by DE" > (or whatever is the right term) different from the > "reserved" value(s) there. [PS:] Agreed will describe the 0xffff... situation in the IANA consideratio= ns and make the 9+ into a to be assigned range. >=20 > (9) 3.6, is it really ok for the "TLS session initiator" to > always be the one who proposes the versions in the version > request message? You still allow the NEA server to be the > TLS session initiator so what'd happen with this then is > confusing - the naughty client could get to pick the > weakest version of PT-TLS that the server supports? 3.7 > also seems to contradict this, saying that the "PT-TLS > initiator" sends the version request. Maybe there is some > cleaning up needed here? [PS:] The TLS session initiator offers a range of supported versions and th= e responder selects one to use. If an initiator believe a version to be we= ak it shouldn't offer it in the range. However if the initiator considers = several versions to be acceptable it can offer them. Right now we only hav= e 1 version but if for some reason 1.0 is badly broken and 1.1 comes out wi= th the fix, then initiators just offer 1.1. >=20 > (10) 4.1, are you saying here that if any of these trust > relationships do not hold, then PT-TLS ought not be used? > If so, then saying that explicitly would be good. For > example, it could be that with some implementations, e.g. > that use less secure inter-proces communications, a bad > process on a client could invalidate some of these > assumptions, thus (maybe) making PT-TLS unsafe. [PS:] Will try to make this a little more clear. Other countermeasures cou= ld be used if something in the trust model doesn't hold for an implementati= on/deployment. >=20 > (11) section 5: do you mean the NEA client SHOULD (in 2119 > terms) provide an indication here? If not, why not? If so, > what's the criteria for not providing that? (Perhaps if > there is no UI?) Same should/SHOULD question for the last > paragraph, i.e. s/should ensure/SHOULD ensure/ and what's > the exception? [PS:] Will change the SHOULDs.=20 =20 >=20 > (12) section 6: some of the intro text here is not really > for IANA, should it be moved elsewhere? (Mainly the > explanation of PEN handling, which might go up into 3.5 > perhaps?) [PS:] It was provided to provide context to the IANA on how the PEN is defi= ning different name spaces since this will be visible in the repository. T= he text is also discussed elsewhere in the document where implementers will= see it. This is the same text used in the other NEA RFCs. >=20 > (13) section 6.1: you're asking IANA to act as a repository > for non-RFC specifications (sort-of), I think that's maybe > an innovation (not sure) that should be checked out with > IANA, or maybe you've done that or know of a precedent? [PS:] The IANA would just reference the permanent and readily available spe= cification in the repository even if it's not an IETF document. I believe t= his was done in other NEA RFCs. >=20 > (14) 6.2 & 6.3 - do you need to tell IANA or the DE that > entries with PEN value 0 need to be IETF stream RFCs, > or standards-track RFCs, or just RFCs or what? If you > want the DE to be able to add PEN=3D0 entries without > an RFC, I think saying that would be best. [PS:] We are following the RFC 5226 policies of "Specification Required" wh= ich says a=20 "permanent and readily available" document must be defined. This doesn't n= eed to be an RFC. This was thoroughly discussed by the WG in the past and = agreed to for previous NEA RFCs. >=20 > (15) References: can we not make the reference to 4346 (TLS > 1.1) informative and craft language to make that work? E.g. > say you SHOULD support TLS1.2 but that in reality a lot of > people still don't and are only doing 4346 as of now? I > think if you do that you can argue that TLS 1.1 is not > a normative reference and that'd be better in future once > most everyone has caught up with TLS1.2. [PS:] We discussed this a couple times in the working group and this was th= e suggested approach due to the lack of 1.2 implementations. We need to ha= ve a MUST and it seems premature to have that be 1.2 as it might hold up im= plementations. This represents the working group consensus. Hopefully the= downgraded reference isn't a show stopper for the IESG. [PS:] If you are ok with the above responses, I'd be happy to put out anoth= er revision early next week so the document can continue to make progress. Thanks, Paul From stephen.farrell@cs.tcd.ie Sat May 26 08:53:53 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB8421F84E6 for ; Sat, 26 May 2012 08:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, 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 iPdulrZWkt1A for ; Sat, 26 May 2012 08:53:51 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F20821F8568 for ; Sat, 26 May 2012 08:53:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0701A1542E3; Sat, 26 May 2012 16:53:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338047627; bh=0IZnmgvHh/gLra 7crh/Ykxa+mXnkmJmlxpU5RDniIz8=; b=r2tatfMzYUWtzbrQDkr/nhWWwTbkAD Q4KoKkAy2MkFa0bytVZkLv/cLlQP6keJrRWuYs2xGxZW7tkjdLF/XE1CrqOk8SCB 8ktt+fYt+X959Mum2GjTh82SVOZbY4F+JM5L+5pN5Op4DQnDuh+S00PE3mjkctWW ycFmARx/J8NK409rF8lRnhmpuGVgU2BYTZO+qIobHbAfh3TIV+t8y+LP70cSD4w5 7dUUMjGYFWV1DvTTMVtJMXEq269ewvKM8DMx0GetP4nwU2bRAdjYGcYuNqlL5au2 e1LM5U9yYpCCaFsD/JwecxhoM3GSlMG3OD3Ijk1L3SezdcJyY1Vlve4g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id m9+3DDCjtHA8; Sat, 26 May 2012 16:53:47 +0100 (IST) Received: from [10.87.48.8] (unknown [86.44.70.236]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A097C1542E1; Sat, 26 May 2012 16:53:47 +0100 (IST) Message-ID: <4FC0FC8A.5030708@cs.tcd.ie> Date: Sat, 26 May 2012 16:53:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Sangster References: <4FB4EA34.2020104@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B8861BF65@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> In-Reply-To: <6E79D623502C70419A9EAB18E4D274252B8861BF65@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nea@ietf.org" Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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, 26 May 2012 15:53:53 -0000 On 05/26/2012 03:45 AM, Paul Sangster wrote: > Thanks for the detailed review of the document, some comments are in-lined below for the non-nits: > >> -----Original Message----- >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf Of >> Stephen Farrell >> Sent: Thursday, May 17, 2012 5:08 AM >> To: Stephen Hanna >> Cc: nea@ietf.org >> Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 >> >> >> Hi Steve, >> >> My AD review of this is below. I think question 1 >> is the main one where I have a concern really, the >> others are mostly not-quite-nits or things where I'm >> just asking, or where there'd be an easy fix if >> a change is needed. >> >> I dunno if this will require a revised I-D or not. >> I suspect it will, but will wait for your/the WG's >> response before putting it in that state. Please >> do argue about that if, having seen this review, >> you think this doesn't require another rev. >> >> (And if some of my questions are just dumb, then >> do say, I'm quite used to that:-) >> >> Cheers, >> S. >> >> Questions: >> >> (1) 3.1.1, This says in one place "the NEA Client is >> effectively acting as a TLS server" which I thought was >> going to be more strongly deprecated or entirely removed? >> While you do recommend (RECOMMEND is good 2119 language >> btw) not doing that, it won't work in many cases, so is it >> really worth keeping at all? How about just leaving in the >> first and last paragraphs of 3.1.1? (Would need some more >> edits to fix up, but all of those would simplify the >> document overall.) > > [PS:] We already discussed this one Ack. > >> >> (2) 3.3, last sentence: this says "an attack" - is this >> normative instruction meant to apply only for detected >> Asokan attacks, or does it also apply for any other attack >> at all, or for some others? For example, what if the TLS >> handshake terminates fails for some reason not specifically >> stated in this document? What if some new unexpected attack >> on NEA is discovered - would this MUST apply to that? I >> guess choices are to s/an attack/this attack/ if you just >> want this to cover the Asokan attack, or if a more general >> statement is desirable then maybe adding something >> somewhere else would be right. > > [PS:] Agreed, this was about the Asokan attack so will make that more clear. > >> >> (3) 3.4.2: How do I know that the "TLS Setup" phase has >> completed and how do I enforce the requirement that TLS >> re-negotiation MUST NOT happen after that? The former seems >> unclear unless it means "after the Finished exchanges" in >> which case maybe say so. The latter seems tricky - will >> current TLS implementations allow you to enforce that? > > [PS:] Will clarity its after the Finished messages. Great. > Yes we know of several implementations allowing the renegotiation to be disabled. Disabled entirely or only after Finished? Doesn't the text call for the latter. I'm a bit surprised that a TLS implementation would support that, which do you mean? >> (4) 3.4.1.1: You do validation according to 5280 which is >> fine. But in 5280, revocation checking is optional. Do you >> need to check revocation here? If you do, then do you need >> to say that the NEA client might need to contact an OCSP >> responder, or is some further profiling of how TLS and 5280 >> are used needed? (e.g. OCSP stapling?) There are a bunch >> of reasonable answers possible and I'm fine with any of 'em >> (particularly whatever folks will implement:-) but I >> suspect you may need to say a bit more here. > > [PS:] Will mention that the NEA Client can optionally do revocation checking. Ok. That means you gotta allow HTTP out from the client in most cases though. Not sure what impact that might have on the overall NEA setup. > >> >> (5) 3.4.2.3 - The last sentence is a bit confusing - what >> should happen if a "NEA protocol" may not be able to make >> use of full-duplex? (And maybe s/protocol/implementation/?) >> What do you do if you're one of those or talking to one of >> those? > > [PS:] Its referring to the higher level protocols on top of PT that might not support full-duplex (e.g. PB). So we'll make that more clear. Ok. >> (6) 3.5: I don't think that enterprise numbers [1] are >> restricted to 24 bits - those are OID arcs which are in >> theory unlimited length. What happens if one is larger than >> 24bits? Reserving a number from that registry also probably >> needs an IANA action, and who knows that might conflict >> with something else. I know you set this to zero but I'm >> guessing vendors will use this as well or its used >> elsewhere by NEA so I do wonder. This also affects 3.9. >> (Nits on this as well: That might also be better stated as >> "Implementations of this specification MUST..." just for >> clarity. And it'd be good to put in a link or reference to >> the IANA registry somewhere - not everyone knows what that >> registry is I guess. Also, referring to 0 as an IETF SMI >> Private Entreprise Number might raise a hackle, since >> that's reserved in the IANA registry. Having said all that, >> if you got this past in other NEA RFCs (didn't check) then >> doing the same thing here is probably ok.) >> >> [1] http://www.iana.org/assignments/enterprise-numbers > > [PS:] This approach is what we used in NEA's PA and PB protocols, so we're just staying consistent with that approach in PT-TLS. So far the IANA has only assigned 16 bits worth of PEN so we should have ALONG time before we will exceed the 24 bits assuming a nearly sequential assignment of numbers. Fair enough. However I don't think there's anything calling on IANA to allocate these sequentially so an e.g. 32 bit PEN could be registered anytime. (Say if someone needed to align numbering with some other space.) Your call as to whether to say anything about this or not. >> (7) 3.5, Message Type. I don't understand what "MUST >> interoperate with other parties despite any differences" >> means here and suspect that that 2119 MUST isn't doable. > > [PS:] Will reword these sentences. This is about disallowing implementations to not interoperate with NEA complaints implements since they always require a vendor specific attribute to be used to do an assessment. And unfortunately I also don't understand your explanation either;-) >> >> (8) 3.5, 6.2 Any "reserved" values should really be >> mentioned in the IANA considerations section so IANA don't >> go and give them out, I mean the 0xffff... ones. "9+" is >> also a bit odd in 6.2. You might want to change that to >> specify the exact range "available for allocation by DE" >> (or whatever is the right term) different from the >> "reserved" value(s) there. > > [PS:] Agreed will describe the 0xffff... situation in the IANA considerations and make the 9+ into a to be assigned range. Ack. >> >> (9) 3.6, is it really ok for the "TLS session initiator" to >> always be the one who proposes the versions in the version >> request message? You still allow the NEA server to be the >> TLS session initiator so what'd happen with this then is >> confusing - the naughty client could get to pick the >> weakest version of PT-TLS that the server supports? 3.7 >> also seems to contradict this, saying that the "PT-TLS >> initiator" sends the version request. Maybe there is some >> cleaning up needed here? > > [PS:] The TLS session initiator offers a range of supported versions and the responder selects one to use. If an initiator believe a version to be weak it shouldn't offer it in the range. However if the initiator considers several versions to be acceptable it can offer them. Right now we only have 1 version but if for some reason 1.0 is badly broken and 1.1 comes out with the fix, then initiators just offer 1.1. > >> >> (10) 4.1, are you saying here that if any of these trust >> relationships do not hold, then PT-TLS ought not be used? >> If so, then saying that explicitly would be good. For >> example, it could be that with some implementations, e.g. >> that use less secure inter-proces communications, a bad >> process on a client could invalidate some of these >> assumptions, thus (maybe) making PT-TLS unsafe. > > [PS:] Will try to make this a little more clear. Other countermeasures could be used if something in the trust model doesn't hold for an implementation/deployment. I don't get your response addresses the question sorry. >> >> (11) section 5: do you mean the NEA client SHOULD (in 2119 >> terms) provide an indication here? If not, why not? If so, >> what's the criteria for not providing that? (Perhaps if >> there is no UI?) Same should/SHOULD question for the last >> paragraph, i.e. s/should ensure/SHOULD ensure/ and what's >> the exception? > > [PS:] Will change the SHOULDs. Ok. I'll look at the results of whatever change you mean:-) >> >> (12) section 6: some of the intro text here is not really >> for IANA, should it be moved elsewhere? (Mainly the >> explanation of PEN handling, which might go up into 3.5 >> perhaps?) > > [PS:] It was provided to provide context to the IANA on how the PEN is defining different name spaces since this will be visible in the repository. The text is also discussed elsewhere in the document where implementers will see it. This is the same text used in the other NEA RFCs. Ok. You may get other AD comments on this later but we'll deal with 'em as they come. >> >> (13) section 6.1: you're asking IANA to act as a repository >> for non-RFC specifications (sort-of), I think that's maybe >> an innovation (not sure) that should be checked out with >> IANA, or maybe you've done that or know of a precedent? > > [PS:] The IANA would just reference the permanent and readily available specification in the repository even if it's not an IETF document. I believe this was done in other NEA RFCs. This is the text I meant: "However, in this latter case, the vendor MUST supply a copy to the IANA and authorize the IANA to archive this copy and make it freely available to all if at some point the document becomes no longer freely available to all through other channels." That's more than referencing, isn't it? But yes, its in RFC 5793 all right, so leave it as is. >> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that >> entries with PEN value 0 need to be IETF stream RFCs, >> or standards-track RFCs, or just RFCs or what? If you >> want the DE to be able to add PEN=0 entries without >> an RFC, I think saying that would be best. > > [PS:] We are following the RFC 5226 policies of "Specification Required" which says a > "permanent and readily available" document must be defined. This doesn't need to be an RFC. This was thoroughly discussed by the WG in the past and agreed to for previous NEA RFCs. But earlier (3.5) it said: If the PT-TLS Message Type Vendor ID field has the value zero (0), then the PT-TLS Message Type field contains an IETF Standard PT-TLS Message Type, as listed in the IANA registry. "IETF standard" != "specification required" so the question stands. (Could be that previous NEA RFCs contain this ambiguity, if it is one. That would not mean we shouldn't fix it here.) >> (15) References: can we not make the reference to 4346 (TLS >> 1.1) informative and craft language to make that work? E.g. >> say you SHOULD support TLS1.2 but that in reality a lot of >> people still don't and are only doing 4346 as of now? I >> think if you do that you can argue that TLS 1.1 is not >> a normative reference and that'd be better in future once >> most everyone has caught up with TLS1.2. > > [PS:] We discussed this a couple times in the working group and this was the suggested approach due to the lack of 1.2 implementations. We need to have a MUST and it seems premature to have that be 1.2 as it might hold up implementations. This represents the working group consensus. Hopefully the downgraded reference isn't a show stopper for the IESG. I get the concern but don't think this is quite the right approach. OAuth had the same concern and their solution might be on to copy. [1] [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-1.6 > [PS:] If you are ok with the above responses, I'd be happy to put out another revision early next week so the document can continue to make progress. Almost all will be fine, might need a bit more chatting on a few. Your call if you wanna iterate those some more via email or draft revision(s). S > Thanks, > Paul > From Paul_Sangster@symantec.com Sun May 27 10:00:40 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8C321F8505 for ; Sun, 27 May 2012 10:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.474 X-Spam-Level: X-Spam-Status: No, score=-4.474 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, MANGLED_PENIS=2.3, 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 V+huuvo5O-7x for ; Sun, 27 May 2012 10:00:39 -0700 (PDT) Received: from tus1smtoutpex03.symantec.com (tus1smtoutpex03.symantec.com [216.10.195.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB5D21F84FF for ; Sun, 27 May 2012 10:00:39 -0700 (PDT) X-AuditID: d80ac3f3-b7f126d000003394-09-4fc25db6626b Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) by tus1smtoutpex03.symantec.com (Symantec Brightmail Gateway out) with SMTP id DB.EE.13204.6BD52CF4; Sun, 27 May 2012 17:00:38 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1SYgpV-0002eD-F7; Sun, 27 May 2012 17:00:33 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([169.254.188.134]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Sun, 27 May 2012 10:00:33 -0700 From: Paul Sangster To: Stephen Farrell Date: Sun, 27 May 2012 10:01:24 -0700 Thread-Topic: [Nea] AD review of draft-ietf-nea-pt-tls-04 Thread-Index: Ac07V8AbSTKczODaQfyKkFzrQrZLqQAznL3Q Message-ID: <6E79D623502C70419A9EAB18E4D274252B8861BFA5@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4FB4EA34.2020104@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B8861BF65@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FC0FC8A.5030708@cs.tcd.ie> In-Reply-To: <4FC0FC8A.5030708@cs.tcd.ie> 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+NgFprLIsWRmVeSWpSXmKPExsVyYMU1bd1tsYf8DZY1q1h8flthMX3vNXYH Jo+13VfZPJYs+ckUwBTFZZOSmpNZllqkb5fAlTHn7ByWgqPlFatnzGVvYFwU28XIySEhYCIx ff5eJghbTOLCvfVsXYxcHEICHxgl1nUtZ4VwXjNKnJy6jQXCWQ3kHNjMDNLCJmAgsfPIKXYQ W0RAX2Lv5nNgNrOAosT01qVgY1kEVCX2XroDZgsLWEjcWrCYEaLeUuLIpU8sELaRxIJlz8Fq eAWiJF6+/gS1+RajxOP7y8CKOAU0JSYt2skKYjMC3fr91BomiGXiEreezIf6QUBiyZ7zzBC2 qMTLx/+g6kUl7rSvZ4So15FYsPsTG4StLbFs4WtmiMWCEidnPmGZwCg+C8nYWUhaZiFpmYWk ZQEjyypGmZLSYsPi3JL80pKC1AoDY73iytxEYJQl6yXn525iBEbaDa7Dn3cwLvyhf4hRgINR iYc3OPSQvxBrYhlQ5SFGCQ5mJRHe/A0H/YV4UxIrq1KL8uOLSnNSiw8xSnOwKInzJuzf6i8k kJ5YkpqdmlqQWgSTZeLglGpgZHCdzrndx9K5os/3wDpmFYvkPYk9nJOj5Y0rD1p+fNV4dGbj 6iuvO48tezdx4/y4k/qMSjFLbhzUj72+iOWd9DvLSP7ChS8n36ucsrPg2duqPWaf1CVXR554 3xZT90lOMEfnWO4dPzaN+wfMXrIXty1UeZuofu7EgbymRcqT71zVa332JKVaT4mlOCPRUIu5 qDgRADvkCQCwAgAA Cc: "nea@ietf.org" Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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: Sun, 27 May 2012 17:00:41 -0000 Responses are in-lined... > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Saturday, May 26, 2012 8:54 AM > To: Paul Sangster > Cc: nea@ietf.org > Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 > > > > On 05/26/2012 03:45 AM, Paul Sangster wrote: > > Thanks for the detailed review of the document, some comments are in- > lined below for the non-nits: > > > >> -----Original Message----- > >> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf > Of > >> Stephen Farrell > >> Sent: Thursday, May 17, 2012 5:08 AM > >> To: Stephen Hanna > >> Cc: nea@ietf.org > >> Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 > >> > >> > >> Hi Steve, > >> > >> My AD review of this is below. I think question 1 > >> is the main one where I have a concern really, the > >> others are mostly not-quite-nits or things where I'm > >> just asking, or where there'd be an easy fix if > >> a change is needed. > >> > >> I dunno if this will require a revised I-D or not. > >> I suspect it will, but will wait for your/the WG's > >> response before putting it in that state. Please > >> do argue about that if, having seen this review, > >> you think this doesn't require another rev. > >> > >> (And if some of my questions are just dumb, then > >> do say, I'm quite used to that:-) > >> > >> Cheers, > >> S. > >> > >> Questions: > >> > >> (1) 3.1.1, This says in one place "the NEA Client is > >> effectively acting as a TLS server" which I thought was > >> going to be more strongly deprecated or entirely removed? > >> While you do recommend (RECOMMEND is good 2119 language > >> btw) not doing that, it won't work in many cases, so is it > >> really worth keeping at all? How about just leaving in the > >> first and last paragraphs of 3.1.1? (Would need some more > >> edits to fix up, but all of those would simplify the > >> document overall.) > > > > [PS:] We already discussed this one > > Ack. > > > > >> > >> (2) 3.3, last sentence: this says "an attack" - is this > >> normative instruction meant to apply only for detected > >> Asokan attacks, or does it also apply for any other attack > >> at all, or for some others? For example, what if the TLS > >> handshake terminates fails for some reason not specifically > >> stated in this document? What if some new unexpected attack > >> on NEA is discovered - would this MUST apply to that? I > >> guess choices are to s/an attack/this attack/ if you just > >> want this to cover the Asokan attack, or if a more general > >> statement is desirable then maybe adding something > >> somewhere else would be right. > > > > [PS:] Agreed, this was about the Asokan attack so will make that more > clear. > > > >> > >> (3) 3.4.2: How do I know that the "TLS Setup" phase has > >> completed and how do I enforce the requirement that TLS > >> re-negotiation MUST NOT happen after that? The former seems > >> unclear unless it means "after the Finished exchanges" in > >> which case maybe say so. The latter seems tricky - will > >> current TLS implementations allow you to enforce that? > > > > [PS:] Will clarity its after the Finished messages. > > Great. > > > Yes we know of several implementations allowing the renegotiation to > be disabled. > > Disabled entirely or only after Finished? Doesn't the text > call for the latter. I'm a bit surprised that a TLS > implementation would support that, which do you mean? [PS:] Yes, in our case its after the Finished messages. OpenSSL and Java = have registerable callbacks that could be used to achieve this. > > >> (4) 3.4.1.1: You do validation according to 5280 which is > >> fine. But in 5280, revocation checking is optional. Do you > >> need to check revocation here? If you do, then do you need > >> to say that the NEA client might need to contact an OCSP > >> responder, or is some further profiling of how TLS and 5280 > >> are used needed? (e.g. OCSP stapling?) There are a bunch > >> of reasonable answers possible and I'm fine with any of 'em > >> (particularly whatever folks will implement:-) but I > >> suspect you may need to say a bit more here. > > > > [PS:] Will mention that the NEA Client can optionally do revocation > checking. > > Ok. That means you gotta allow HTTP out from the > client in most cases though. Not sure what impact that might > have on the overall NEA setup. [PS:] Agreed, if the client isn't using a local CRL. In this case, the cli= ent is already on the network and is being re-assessed so suspect the clien= t already has HTTL access so this shouldn't be a problem for most deploymen= ts. > > > > >> > >> (5) 3.4.2.3 - The last sentence is a bit confusing - what > >> should happen if a "NEA protocol" may not be able to make > >> use of full-duplex? (And maybe s/protocol/implementation/?) > >> What do you do if you're one of those or talking to one of > >> those? > > > > [PS:] Its referring to the higher level protocols on top of PT that > might not support full-duplex (e.g. PB). So we'll make that more clear. > > Ok. > > >> (6) 3.5: I don't think that enterprise numbers [1] are > >> restricted to 24 bits - those are OID arcs which are in > >> theory unlimited length. What happens if one is larger than > >> 24bits? Reserving a number from that registry also probably > >> needs an IANA action, and who knows that might conflict > >> with something else. I know you set this to zero but I'm > >> guessing vendors will use this as well or its used > >> elsewhere by NEA so I do wonder. This also affects 3.9. > >> (Nits on this as well: That might also be better stated as > >> "Implementations of this specification MUST..." just for > >> clarity. And it'd be good to put in a link or reference to > >> the IANA registry somewhere - not everyone knows what that > >> registry is I guess. Also, referring to 0 as an IETF SMI > >> Private Entreprise Number might raise a hackle, since > >> that's reserved in the IANA registry. Having said all that, > >> if you got this past in other NEA RFCs (didn't check) then > >> doing the same thing here is probably ok.) > >> > >> [1] http://www.iana.org/assignments/enterprise-numbers > > > > [PS:] This approach is what we used in NEA's PA and PB protocols, so > we're just staying consistent with that approach in PT-TLS. So far the > IANA has only assigned 16 bits worth of PEN so we should have ALONG > time before we will exceed the 24 bits assuming a nearly sequential > assignment of numbers. > > Fair enough. However I don't think there's anything calling > on IANA to allocate these sequentially so an e.g. 32 bit PEN > could be registered anytime. (Say if someone needed to align > numbering with some other space.) Your call as to whether to > say anything about this or not. [PS:] So are you suggesting we add text to the IANA considerations to highl= ight that we're counting on them continuing to do a sequential assignment o= f numbers so as to maximize the time the 24 bits will be sufficient? > > > >> (7) 3.5, Message Type. I don't understand what "MUST > >> interoperate with other parties despite any differences" > >> means here and suspect that that 2119 MUST isn't doable. > > > > [PS:] Will reword these sentences. This is about disallowing > implementations to not interoperate with NEA complaints implements > since they always require a vendor specific attribute to be used to do > an assessment. > > And unfortunately I also don't understand your explanation > either;-) [PS:] Re-reading I can see why :). We're trying to avoid the situation whe= re a vendor implements PT-TLS and claims to be compliant with the spec yet = won't interoperate with other PT-TLS compliant implementations because they= will only function after being given a vendor-specific attribute in the ex= change. > > >> > >> (8) 3.5, 6.2 Any "reserved" values should really be > >> mentioned in the IANA considerations section so IANA don't > >> go and give them out, I mean the 0xffff... ones. "9+" is > >> also a bit odd in 6.2. You might want to change that to > >> specify the exact range "available for allocation by DE" > >> (or whatever is the right term) different from the > >> "reserved" value(s) there. > > > > [PS:] Agreed will describe the 0xffff... situation in the IANA > considerations and make the 9+ into a to be assigned range. > > Ack. > > >> > >> (9) 3.6, is it really ok for the "TLS session initiator" to > >> always be the one who proposes the versions in the version > >> request message? You still allow the NEA server to be the > >> TLS session initiator so what'd happen with this then is > >> confusing - the naughty client could get to pick the > >> weakest version of PT-TLS that the server supports? 3.7 > >> also seems to contradict this, saying that the "PT-TLS > >> initiator" sends the version request. Maybe there is some > >> cleaning up needed here? > > > > [PS:] The TLS session initiator offers a range of supported versions > and the responder selects one to use. If an initiator believe a > version to be weak it shouldn't offer it in the range. However if the > initiator considers several versions to be acceptable it can offer them. > Right now we only have 1 version but if for some reason 1.0 is badly > broken and 1.1 comes out with the fix, then initiators just offer 1.1. > > > >> > >> (10) 4.1, are you saying here that if any of these trust > >> relationships do not hold, then PT-TLS ought not be used? > >> If so, then saying that explicitly would be good. For > >> example, it could be that with some implementations, e.g. > >> that use less secure inter-proces communications, a bad > >> process on a client could invalidate some of these > >> assumptions, thus (maybe) making PT-TLS unsafe. > > > > [PS:] Will try to make this a little more clear. Other > countermeasures could be used if something in the trust model doesn't > hold for an implementation/deployment. > > I don't get your response addresses the question sorry. [PS:] Yes, I was agreeing with your comment and mentioning that the custome= r could have other mitigating controls or countermeasures that would still = allow PT-TLS to be used. > > >> > >> (11) section 5: do you mean the NEA client SHOULD (in 2119 > >> terms) provide an indication here? If not, why not? If so, > >> what's the criteria for not providing that? (Perhaps if > >> there is no UI?) Same should/SHOULD question for the last > >> paragraph, i.e. s/should ensure/SHOULD ensure/ and what's > >> the exception? > > > > [PS:] Will change the SHOULDs. > > Ok. I'll look at the results of whatever change you mean:-) [PS:] will change the "should" to "SHOULD" as you suggested if the software= has a UI. > > >> > >> (12) section 6: some of the intro text here is not really > >> for IANA, should it be moved elsewhere? (Mainly the > >> explanation of PEN handling, which might go up into 3.5 > >> perhaps?) > > > > [PS:] It was provided to provide context to the IANA on how the PEN > is defining different name spaces since this will be visible in the > repository. The text is also discussed elsewhere in the document where > implementers will see it. This is the same text used in the other NEA > RFCs. > > Ok. You may get other AD comments on this later but > we'll deal with 'em as they come. [PS:] Ok. I don't recall PA or PB receiving IESG comments about this text = but that was a few years ago. > > >> > >> (13) section 6.1: you're asking IANA to act as a repository > >> for non-RFC specifications (sort-of), I think that's maybe > >> an innovation (not sure) that should be checked out with > >> IANA, or maybe you've done that or know of a precedent? > > > > [PS:] The IANA would just reference the permanent and readily > available specification in the repository even if it's not an IETF > document. I believe this was done in other NEA RFCs. > > This is the text I meant: > > "However, in this latter > case, the vendor MUST supply a copy to the IANA and authorize > the IANA to archive this copy and make it freely available to > all if at some point the document becomes no longer freely > available to all through other channels." > > That's more than referencing, isn't it? But yes, its in > RFC 5793 all right, so leave it as is. > > >> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that > >> entries with PEN value 0 need to be IETF stream RFCs, > >> or standards-track RFCs, or just RFCs or what? If you > >> want the DE to be able to add PEN=3D0 entries without > >> an RFC, I think saying that would be best. > > > > [PS:] We are following the RFC 5226 policies of "Specification > Required" which says a > > "permanent and readily available" document must be defined. This > doesn't need to be an RFC. This was thoroughly discussed by the WG in > the past and agreed to for previous NEA RFCs. > > But earlier (3.5) it said: > > If the PT-TLS Message Type Vendor ID field has the value zero > (0), then the PT-TLS Message Type field contains an IETF Standard > PT-TLS Message Type, as listed in the IANA registry. > > "IETF standard" !=3D "specification required" so the question stands. > (Could be that previous NEA RFCs contain this ambiguity, if it is > one. That would not mean we shouldn't fix it here.) [PS:] Good point, maybe that should say "IETF namespace" instead of "IETF s= tandard". > > >> (15) References: can we not make the reference to 4346 (TLS > >> 1.1) informative and craft language to make that work? E.g. > >> say you SHOULD support TLS1.2 but that in reality a lot of > >> people still don't and are only doing 4346 as of now? I > >> think if you do that you can argue that TLS 1.1 is not > >> a normative reference and that'd be better in future once > >> most everyone has caught up with TLS1.2. > > > > [PS:] We discussed this a couple times in the working group and this > was the suggested approach due to the lack of 1.2 implementations. We > need to have a MUST and it seems premature to have that be 1.2 as it > might hold up implementations. This represents the working group > consensus. Hopefully the downgraded reference isn't a show stopper for > the IESG. > > I get the concern but don't think this is quite the right > approach. > > OAuth had the same concern and their solution might be on > to copy. [1] > > [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-1.6 [PS:] I don't have a problem with doing something more like this but of cou= rse it means we wouldn't have a MUST implement version of TLS which could c= ause interop issues. Any objections to going this route? > > > [PS:] If you are ok with the above responses, I'd be happy to put out > another revision early next week so the document can continue to make > progress. > > Almost all will be fine, might need a bit more chatting on > a few. Your call if you wanna iterate those some more via email > or draft revision(s). > > S > > > Thanks, > > Paul > > From stephen.farrell@cs.tcd.ie Sun May 27 15:15:12 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD3121F8442 for ; Sun, 27 May 2012 15:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.699 X-Spam-Level: X-Spam-Status: No, score=-99.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MANGLED_PENIS=2.3, 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 ng1MAcSC6xn0 for ; Sun, 27 May 2012 15:15:09 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A28B021F84FA for ; Sun, 27 May 2012 15:15:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id BB20017158D; Sun, 27 May 2012 23:14:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338156895; bh=XJSaQvIyCN8Vlh 6g/WhOJrefeLFho2zQtpHZNimeBoI=; b=guWbyB4zypuaBbisBnu2jH2Nu0a8Ie qTMYO/Gr2+mFsfwlC0iTIwPLt6BP7gIH1JuDJL2VDGFQt35M2xdBkTjtgYZCTzPx pLpB5s39Ti/3pDY+mwdWNOBue+GT+bWCKwLAvL0KjgbxhIuXUwVPQOi3TAaOEB6C UP++wzZlVpmblaJtTZsh2hBcUXAMgz55SjYABdEMO9R9/lRL/P0USiFDBqt9sAzX 6O5xuJjUV0kFmgyfTMSzeH5CRGKENnK3lZLpnJke15OGhcgH0XA6JywAHZIqIp1d v4wT7LIoTMnLKd0Ai2Wvdt5fuQ6d3f27eZPH7miuRQ8wmwP1fmRBzkaQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id Z11jx7mrOUIs; Sun, 27 May 2012 23:14:55 +0100 (IST) Received: from [10.87.48.8] (unknown [86.45.53.50]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 07B571714EC; Sun, 27 May 2012 23:14:53 +0100 (IST) Message-ID: <4FC2A75C.2000701@cs.tcd.ie> Date: Sun, 27 May 2012 23:14:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Sangster References: <4FB4EA34.2020104@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B8861BF65@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FC0FC8A.5030708@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B8861BFA5@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> In-Reply-To: <6E79D623502C70419A9EAB18E4D274252B8861BFA5@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nea@ietf.org" Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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: Sun, 27 May 2012 22:15:12 -0000 Hi Paul, Feel free to spin another rev whenever, I reckon we're nearly there anyway. I think the only remaining one is the PEN=0 IANA consideration. I'd be fine to issue the IETF LC with that outstanding if need be, but better if we can get it sorted before that. I'm not clear as to the precise intent of the WG on this, so if folks could take a look that'd be good. (That's issue 13 below) Cheers, S On 05/27/2012 06:01 PM, Paul Sangster wrote: > Responses are in-lined... > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Saturday, May 26, 2012 8:54 AM >> To: Paul Sangster >> Cc: nea@ietf.org >> Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 >> >> >> >> On 05/26/2012 03:45 AM, Paul Sangster wrote: >>> Thanks for the detailed review of the document, some comments are in- >> lined below for the non-nits: >>> >>>> -----Original Message----- >>>> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf >> Of >>>> Stephen Farrell >>>> Sent: Thursday, May 17, 2012 5:08 AM >>>> To: Stephen Hanna >>>> Cc: nea@ietf.org >>>> Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 >>>> >>>> >>>> Hi Steve, >>>> >>>> My AD review of this is below. I think question 1 >>>> is the main one where I have a concern really, the >>>> others are mostly not-quite-nits or things where I'm >>>> just asking, or where there'd be an easy fix if >>>> a change is needed. >>>> >>>> I dunno if this will require a revised I-D or not. >>>> I suspect it will, but will wait for your/the WG's >>>> response before putting it in that state. Please >>>> do argue about that if, having seen this review, >>>> you think this doesn't require another rev. >>>> >>>> (And if some of my questions are just dumb, then >>>> do say, I'm quite used to that:-) >>>> >>>> Cheers, >>>> S. >>>> >>>> Questions: >>>> >>>> (1) 3.1.1, This says in one place "the NEA Client is >>>> effectively acting as a TLS server" which I thought was >>>> going to be more strongly deprecated or entirely removed? >>>> While you do recommend (RECOMMEND is good 2119 language >>>> btw) not doing that, it won't work in many cases, so is it >>>> really worth keeping at all? How about just leaving in the >>>> first and last paragraphs of 3.1.1? (Would need some more >>>> edits to fix up, but all of those would simplify the >>>> document overall.) >>> >>> [PS:] We already discussed this one >> >> Ack. >> >>> >>>> >>>> (2) 3.3, last sentence: this says "an attack" - is this >>>> normative instruction meant to apply only for detected >>>> Asokan attacks, or does it also apply for any other attack >>>> at all, or for some others? For example, what if the TLS >>>> handshake terminates fails for some reason not specifically >>>> stated in this document? What if some new unexpected attack >>>> on NEA is discovered - would this MUST apply to that? I >>>> guess choices are to s/an attack/this attack/ if you just >>>> want this to cover the Asokan attack, or if a more general >>>> statement is desirable then maybe adding something >>>> somewhere else would be right. >>> >>> [PS:] Agreed, this was about the Asokan attack so will make that more >> clear. >>> >>>> >>>> (3) 3.4.2: How do I know that the "TLS Setup" phase has >>>> completed and how do I enforce the requirement that TLS >>>> re-negotiation MUST NOT happen after that? The former seems >>>> unclear unless it means "after the Finished exchanges" in >>>> which case maybe say so. The latter seems tricky - will >>>> current TLS implementations allow you to enforce that? >>> >>> [PS:] Will clarity its after the Finished messages. >> >> Great. >> >>> Yes we know of several implementations allowing the renegotiation to >> be disabled. >> >> Disabled entirely or only after Finished? Doesn't the text >> call for the latter. I'm a bit surprised that a TLS >> implementation would support that, which do you mean? > > [PS:] Yes, in our case its after the Finished messages. OpenSSL and Java have registerable callbacks that could be used to achieve this. I'm still surprised that you can disable renego like that after the Finished, but ok, let's see if someone reacts to it during IETF LC. >> >>>> (4) 3.4.1.1: You do validation according to 5280 which is >>>> fine. But in 5280, revocation checking is optional. Do you >>>> need to check revocation here? If you do, then do you need >>>> to say that the NEA client might need to contact an OCSP >>>> responder, or is some further profiling of how TLS and 5280 >>>> are used needed? (e.g. OCSP stapling?) There are a bunch >>>> of reasonable answers possible and I'm fine with any of 'em >>>> (particularly whatever folks will implement:-) but I >>>> suspect you may need to say a bit more here. >>> >>> [PS:] Will mention that the NEA Client can optionally do revocation >> checking. >> >> Ok. That means you gotta allow HTTP out from the >> client in most cases though. Not sure what impact that might >> have on the overall NEA setup. > > [PS:] Agreed, if the client isn't using a local CRL. In this case, the client is already on the network and is being re-assessed so suspect the client already has HTTL access so this shouldn't be a problem for most deployments. > >> >>> >>>> >>>> (5) 3.4.2.3 - The last sentence is a bit confusing - what >>>> should happen if a "NEA protocol" may not be able to make >>>> use of full-duplex? (And maybe s/protocol/implementation/?) >>>> What do you do if you're one of those or talking to one of >>>> those? >>> >>> [PS:] Its referring to the higher level protocols on top of PT that >> might not support full-duplex (e.g. PB). So we'll make that more clear. >> >> Ok. >> >>>> (6) 3.5: I don't think that enterprise numbers [1] are >>>> restricted to 24 bits - those are OID arcs which are in >>>> theory unlimited length. What happens if one is larger than >>>> 24bits? Reserving a number from that registry also probably >>>> needs an IANA action, and who knows that might conflict >>>> with something else. I know you set this to zero but I'm >>>> guessing vendors will use this as well or its used >>>> elsewhere by NEA so I do wonder. This also affects 3.9. >>>> (Nits on this as well: That might also be better stated as >>>> "Implementations of this specification MUST..." just for >>>> clarity. And it'd be good to put in a link or reference to >>>> the IANA registry somewhere - not everyone knows what that >>>> registry is I guess. Also, referring to 0 as an IETF SMI >>>> Private Entreprise Number might raise a hackle, since >>>> that's reserved in the IANA registry. Having said all that, >>>> if you got this past in other NEA RFCs (didn't check) then >>>> doing the same thing here is probably ok.) >>>> >>>> [1] http://www.iana.org/assignments/enterprise-numbers >>> >>> [PS:] This approach is what we used in NEA's PA and PB protocols, so >> we're just staying consistent with that approach in PT-TLS. So far the >> IANA has only assigned 16 bits worth of PEN so we should have ALONG >> time before we will exceed the 24 bits assuming a nearly sequential >> assignment of numbers. >> >> Fair enough. However I don't think there's anything calling >> on IANA to allocate these sequentially so an e.g. 32 bit PEN >> could be registered anytime. (Say if someone needed to align >> numbering with some other space.) Your call as to whether to >> say anything about this or not. > > [PS:] So are you suggesting we add text to the IANA considerations to highlight that we're counting on them continuing to do a sequential assignment of numbers so as to maximize the time the 24 bits will be sufficient? Not quite. The sequential allocation is a who-cares, but the 24 bit limit is worth noting maybe. Perhaps something along the lines of "As with RFCs foo,bar we depend here on PEN's being less than 24 bits wide, if IANA were to register a wider PEN then that could not be used with NEA." But as I said, it you wanna leave that out I won't yell since its already the case for other RFCs. >>>> (7) 3.5, Message Type. I don't understand what "MUST >>>> interoperate with other parties despite any differences" >>>> means here and suspect that that 2119 MUST isn't doable. >>> >>> [PS:] Will reword these sentences. This is about disallowing >> implementations to not interoperate with NEA complaints implements >> since they always require a vendor specific attribute to be used to do >> an assessment. >> >> And unfortunately I also don't understand your explanation >> either;-) > > [PS:] Re-reading I can see why :). We're trying to avoid the situation where a vendor implements PT-TLS and claims to be compliant with the spec yet won't interoperate with other PT-TLS compliant implementations because they will only function after being given a vendor-specific attribute in the exchange. Ok, sounds like you really want to say "Implementations MUST support foo,bar,baz featurs of this spec" somewhere. But I guess see what re-wording seems to make sense to you. >> >>>> >>>> (8) 3.5, 6.2 Any "reserved" values should really be >>>> mentioned in the IANA considerations section so IANA don't >>>> go and give them out, I mean the 0xffff... ones. "9+" is >>>> also a bit odd in 6.2. You might want to change that to >>>> specify the exact range "available for allocation by DE" >>>> (or whatever is the right term) different from the >>>> "reserved" value(s) there. >>> >>> [PS:] Agreed will describe the 0xffff... situation in the IANA >> considerations and make the 9+ into a to be assigned range. >> >> Ack. >> >>>> >>>> (9) 3.6, is it really ok for the "TLS session initiator" to >>>> always be the one who proposes the versions in the version >>>> request message? You still allow the NEA server to be the >>>> TLS session initiator so what'd happen with this then is >>>> confusing - the naughty client could get to pick the >>>> weakest version of PT-TLS that the server supports? 3.7 >>>> also seems to contradict this, saying that the "PT-TLS >>>> initiator" sends the version request. Maybe there is some >>>> cleaning up needed here? >>> >>> [PS:] The TLS session initiator offers a range of supported versions >> and the responder selects one to use. If an initiator believe a >> version to be weak it shouldn't offer it in the range. However if the >> initiator considers several versions to be acceptable it can offer them. >> Right now we only have 1 version but if for some reason 1.0 is badly >> broken and 1.1 comes out with the fix, then initiators just offer 1.1. >>> >>>> >>>> (10) 4.1, are you saying here that if any of these trust >>>> relationships do not hold, then PT-TLS ought not be used? >>>> If so, then saying that explicitly would be good. For >>>> example, it could be that with some implementations, e.g. >>>> that use less secure inter-proces communications, a bad >>>> process on a client could invalidate some of these >>>> assumptions, thus (maybe) making PT-TLS unsafe. >>> >>> [PS:] Will try to make this a little more clear. Other >> countermeasures could be used if something in the trust model doesn't >> hold for an implementation/deployment. >> >> I don't get your response addresses the question sorry. > > [PS:] Yes, I was agreeing with your comment and mentioning that the customer could have other mitigating controls or countermeasures that would still allow PT-TLS to be used. Ah. Gotcha. Sounds fine. >> >>>> >>>> (11) section 5: do you mean the NEA client SHOULD (in 2119 >>>> terms) provide an indication here? If not, why not? If so, >>>> what's the criteria for not providing that? (Perhaps if >>>> there is no UI?) Same should/SHOULD question for the last >>>> paragraph, i.e. s/should ensure/SHOULD ensure/ and what's >>>> the exception? >>> >>> [PS:] Will change the SHOULDs. >> >> Ok. I'll look at the results of whatever change you mean:-) > > [PS:] will change the "should" to "SHOULD" as you suggested if the software has a UI. Ok >> >>>> >>>> (12) section 6: some of the intro text here is not really >>>> for IANA, should it be moved elsewhere? (Mainly the >>>> explanation of PEN handling, which might go up into 3.5 >>>> perhaps?) >>> >>> [PS:] It was provided to provide context to the IANA on how the PEN >> is defining different name spaces since this will be visible in the >> repository. The text is also discussed elsewhere in the document where >> implementers will see it. This is the same text used in the other NEA >> RFCs. >> >> Ok. You may get other AD comments on this later but >> we'll deal with 'em as they come. > > [PS:] Ok. I don't recall PA or PB receiving IESG comments about this text but that was a few years ago. > >> >>>> >>>> (13) section 6.1: you're asking IANA to act as a repository >>>> for non-RFC specifications (sort-of), I think that's maybe >>>> an innovation (not sure) that should be checked out with >>>> IANA, or maybe you've done that or know of a precedent? >>> >>> [PS:] The IANA would just reference the permanent and readily >> available specification in the repository even if it's not an IETF >> document. I believe this was done in other NEA RFCs. >> >> This is the text I meant: >> >> "However, in this latter >> case, the vendor MUST supply a copy to the IANA and authorize >> the IANA to archive this copy and make it freely available to >> all if at some point the document becomes no longer freely >> available to all through other channels." >> >> That's more than referencing, isn't it? But yes, its in >> RFC 5793 all right, so leave it as is. >> >>>> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that >>>> entries with PEN value 0 need to be IETF stream RFCs, >>>> or standards-track RFCs, or just RFCs or what? If you >>>> want the DE to be able to add PEN=0 entries without >>>> an RFC, I think saying that would be best. >>> >>> [PS:] We are following the RFC 5226 policies of "Specification >> Required" which says a >>> "permanent and readily available" document must be defined. This >> doesn't need to be an RFC. This was thoroughly discussed by the WG in >> the past and agreed to for previous NEA RFCs. >> >> But earlier (3.5) it said: >> >> If the PT-TLS Message Type Vendor ID field has the value zero >> (0), then the PT-TLS Message Type field contains an IETF Standard >> PT-TLS Message Type, as listed in the IANA registry. >> >> "IETF standard" != "specification required" so the question stands. >> (Could be that previous NEA RFCs contain this ambiguity, if it is >> one. That would not mean we shouldn't fix it here.) > > [PS:] Good point, maybe that should say "IETF namespace" instead of "IETF standard". Well, I guess its just a matter of getting whatever is the intent written down precisely, which can sometimes show up some ambiguity in the intent:-) The question here is does the specification required rule apply to the addition of new entries with PEN=0? If yes, then that's not an IETF namespace either since TCG or whoever could do that. If no, then what rule does apply? > >> >>>> (15) References: can we not make the reference to 4346 (TLS >>>> 1.1) informative and craft language to make that work? E.g. >>>> say you SHOULD support TLS1.2 but that in reality a lot of >>>> people still don't and are only doing 4346 as of now? I >>>> think if you do that you can argue that TLS 1.1 is not >>>> a normative reference and that'd be better in future once >>>> most everyone has caught up with TLS1.2. >>> >>> [PS:] We discussed this a couple times in the working group and this >> was the suggested approach due to the lack of 1.2 implementations. We >> need to have a MUST and it seems premature to have that be 1.2 as it >> might hold up implementations. This represents the working group >> consensus. Hopefully the downgraded reference isn't a show stopper for >> the IESG. >> >> I get the concern but don't think this is quite the right >> approach. >> >> OAuth had the same concern and their solution might be on >> to copy. [1] >> >> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-1.6 > > [PS:] I don't have a problem with doing something more like this but of course it means we wouldn't have a MUST implement version of TLS which could cause interop issues. Any objections to going this route? Yep, its weasel words regardless. Weasel words with precedent are probably better, much though I don't like 'em. (Note that the WG decision here is sensible, but unfortunate.) >>> [PS:] If you are ok with the above responses, I'd be happy to put out >> another revision early next week so the document can continue to make >> progress. >> >> Almost all will be fine, might need a bit more chatting on >> a few. Your call if you wanna iterate those some more via email >> or draft revision(s). >> >> S >> >>> Thanks, >>> Paul >>> > > From stephen.farrell@cs.tcd.ie Tue May 29 03:23:37 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B95721F87BD for ; Tue, 29 May 2012 03:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.232 X-Spam-Level: X-Spam-Status: No, score=-100.232 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, MANGLED_PENIS=2.3, 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 ObcIuieoIHMh for ; Tue, 29 May 2012 03:23:36 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id AB47C21F871C for ; Tue, 29 May 2012 03:23:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 200AD153958; Tue, 29 May 2012 11:23:35 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338287013; bh=twouhxUyhAqC/9 icZQMzUjg/c4i5Cz9gdWf1sCvnOmU=; b=Cz7lr6d6o8dAFAHAl6ctp3h6LSN7lc mxFHnJ8ixHVemSBH697JZ+ZKTKUUzVdfy2bQQKzEYXl1TipojqXPFsct7vTQKxDI 2K3ir/GSoNfb2T6xhLJvtNgjcIbmKsol2yRpkKkfTSK5L5H5xlJ7ywuHi5brY5s5 JQNrkSrYwP+2hQzRriZGMKC7/H7PW9nTVZKwnM9Aye4ss8E+sVRoGJzmLgKuHQY7 +F+kUPj582Lqo+M5yxC6NnOEZwTdVgpPWlYYk+xPrgRCUdAa8IKYYkgR6RxrcMvx h3/M5q3WhdIWUIttwOPnLaNklQY/b+Z1Ckpdgjm97qCZAwrZvRkxtJOQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id k3pOFhzNfCHk; Tue, 29 May 2012 11:23:33 +0100 (IST) Received: from [IPv6:2001:770:10:203:746a:67db:b7ac:1c60] (unknown [IPv6:2001:770:10:203:746a:67db:b7ac:1c60]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B2B31153947; Tue, 29 May 2012 11:23:33 +0100 (IST) Message-ID: <4FC4A3A6.6050803@cs.tcd.ie> Date: Tue, 29 May 2012 11:23:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "nea@ietf.org" References: <4FB4EA34.2020104@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B8861BF65@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FC0FC8A.5030708@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B8861BFA5@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FC2A75C.2000701@cs.tcd.ie> In-Reply-To: <4FC2A75C.2000701@cs.tcd.ie> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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, 29 May 2012 10:23:37 -0000 On 05/27/2012 11:14 PM, Stephen Farrell wrote: > > Hi Paul, > > Feel free to spin another rev whenever, I reckon we're > nearly there anyway. > > I think the only remaining one is the PEN=0 IANA > consideration. > > I'd be fine to issue the IETF LC with that outstanding > if need be, but better if we can get it sorted before > that. I'm not clear as to the precise intent of the > WG on this, so if folks could take a look that'd be > good. (That's issue 13 below) Oops. Its actually issue 14;-) S > > Cheers, > S > > On 05/27/2012 06:01 PM, Paul Sangster wrote: >> Responses are in-lined... >> >>> -----Original Message----- >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>> Sent: Saturday, May 26, 2012 8:54 AM >>> To: Paul Sangster >>> Cc: nea@ietf.org >>> Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 >>> >>> >>> >>> On 05/26/2012 03:45 AM, Paul Sangster wrote: >>>> Thanks for the detailed review of the document, some comments are in- >>> lined below for the non-nits: >>>> >>>>> -----Original Message----- >>>>> From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On Behalf >>> Of >>>>> Stephen Farrell >>>>> Sent: Thursday, May 17, 2012 5:08 AM >>>>> To: Stephen Hanna >>>>> Cc: nea@ietf.org >>>>> Subject: [Nea] AD review of draft-ietf-nea-pt-tls-04 >>>>> >>>>> >>>>> Hi Steve, >>>>> >>>>> My AD review of this is below. I think question 1 >>>>> is the main one where I have a concern really, the >>>>> others are mostly not-quite-nits or things where I'm >>>>> just asking, or where there'd be an easy fix if >>>>> a change is needed. >>>>> >>>>> I dunno if this will require a revised I-D or not. >>>>> I suspect it will, but will wait for your/the WG's >>>>> response before putting it in that state. Please >>>>> do argue about that if, having seen this review, >>>>> you think this doesn't require another rev. >>>>> >>>>> (And if some of my questions are just dumb, then >>>>> do say, I'm quite used to that:-) >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> Questions: >>>>> >>>>> (1) 3.1.1, This says in one place "the NEA Client is >>>>> effectively acting as a TLS server" which I thought was >>>>> going to be more strongly deprecated or entirely removed? >>>>> While you do recommend (RECOMMEND is good 2119 language >>>>> btw) not doing that, it won't work in many cases, so is it >>>>> really worth keeping at all? How about just leaving in the >>>>> first and last paragraphs of 3.1.1? (Would need some more >>>>> edits to fix up, but all of those would simplify the >>>>> document overall.) >>>> >>>> [PS:] We already discussed this one >>> >>> Ack. >>> >>>> >>>>> >>>>> (2) 3.3, last sentence: this says "an attack" - is this >>>>> normative instruction meant to apply only for detected >>>>> Asokan attacks, or does it also apply for any other attack >>>>> at all, or for some others? For example, what if the TLS >>>>> handshake terminates fails for some reason not specifically >>>>> stated in this document? What if some new unexpected attack >>>>> on NEA is discovered - would this MUST apply to that? I >>>>> guess choices are to s/an attack/this attack/ if you just >>>>> want this to cover the Asokan attack, or if a more general >>>>> statement is desirable then maybe adding something >>>>> somewhere else would be right. >>>> >>>> [PS:] Agreed, this was about the Asokan attack so will make that more >>> clear. >>>> >>>>> >>>>> (3) 3.4.2: How do I know that the "TLS Setup" phase has >>>>> completed and how do I enforce the requirement that TLS >>>>> re-negotiation MUST NOT happen after that? The former seems >>>>> unclear unless it means "after the Finished exchanges" in >>>>> which case maybe say so. The latter seems tricky - will >>>>> current TLS implementations allow you to enforce that? >>>> >>>> [PS:] Will clarity its after the Finished messages. >>> >>> Great. >>> >>>> Yes we know of several implementations allowing the renegotiation to >>> be disabled. >>> >>> Disabled entirely or only after Finished? Doesn't the text >>> call for the latter. I'm a bit surprised that a TLS >>> implementation would support that, which do you mean? >> >> [PS:] Yes, in our case its after the Finished messages. OpenSSL and Java have registerable callbacks that could be used to achieve this. > > I'm still surprised that you can disable renego like that > after the Finished, but ok, let's see if someone reacts > to it during IETF LC. > >>> >>>>> (4) 3.4.1.1: You do validation according to 5280 which is >>>>> fine. But in 5280, revocation checking is optional. Do you >>>>> need to check revocation here? If you do, then do you need >>>>> to say that the NEA client might need to contact an OCSP >>>>> responder, or is some further profiling of how TLS and 5280 >>>>> are used needed? (e.g. OCSP stapling?) There are a bunch >>>>> of reasonable answers possible and I'm fine with any of 'em >>>>> (particularly whatever folks will implement:-) but I >>>>> suspect you may need to say a bit more here. >>>> >>>> [PS:] Will mention that the NEA Client can optionally do revocation >>> checking. >>> >>> Ok. That means you gotta allow HTTP out from the >>> client in most cases though. Not sure what impact that might >>> have on the overall NEA setup. >> >> [PS:] Agreed, if the client isn't using a local CRL. In this case, the client is already on the network and is being re-assessed so suspect the client already has HTTL access so this shouldn't be a problem for most deployments. >> >>> >>>> >>>>> >>>>> (5) 3.4.2.3 - The last sentence is a bit confusing - what >>>>> should happen if a "NEA protocol" may not be able to make >>>>> use of full-duplex? (And maybe s/protocol/implementation/?) >>>>> What do you do if you're one of those or talking to one of >>>>> those? >>>> >>>> [PS:] Its referring to the higher level protocols on top of PT that >>> might not support full-duplex (e.g. PB). So we'll make that more clear. >>> >>> Ok. >>> >>>>> (6) 3.5: I don't think that enterprise numbers [1] are >>>>> restricted to 24 bits - those are OID arcs which are in >>>>> theory unlimited length. What happens if one is larger than >>>>> 24bits? Reserving a number from that registry also probably >>>>> needs an IANA action, and who knows that might conflict >>>>> with something else. I know you set this to zero but I'm >>>>> guessing vendors will use this as well or its used >>>>> elsewhere by NEA so I do wonder. This also affects 3.9. >>>>> (Nits on this as well: That might also be better stated as >>>>> "Implementations of this specification MUST..." just for >>>>> clarity. And it'd be good to put in a link or reference to >>>>> the IANA registry somewhere - not everyone knows what that >>>>> registry is I guess. Also, referring to 0 as an IETF SMI >>>>> Private Entreprise Number might raise a hackle, since >>>>> that's reserved in the IANA registry. Having said all that, >>>>> if you got this past in other NEA RFCs (didn't check) then >>>>> doing the same thing here is probably ok.) >>>>> >>>>> [1] http://www.iana.org/assignments/enterprise-numbers >>>> >>>> [PS:] This approach is what we used in NEA's PA and PB protocols, so >>> we're just staying consistent with that approach in PT-TLS. So far the >>> IANA has only assigned 16 bits worth of PEN so we should have ALONG >>> time before we will exceed the 24 bits assuming a nearly sequential >>> assignment of numbers. >>> >>> Fair enough. However I don't think there's anything calling >>> on IANA to allocate these sequentially so an e.g. 32 bit PEN >>> could be registered anytime. (Say if someone needed to align >>> numbering with some other space.) Your call as to whether to >>> say anything about this or not. >> >> [PS:] So are you suggesting we add text to the IANA considerations to highlight that we're counting on them continuing to do a sequential assignment of numbers so as to maximize the time the 24 bits will be sufficient? > > Not quite. The sequential allocation is a who-cares, but the > 24 bit limit is worth noting maybe. Perhaps something along > the lines of "As with RFCs foo,bar we depend here on PEN's > being less than 24 bits wide, if IANA were to register a > wider PEN then that could not be used with NEA." > > But as I said, it you wanna leave that out I won't yell > since its already the case for other RFCs. > >>>>> (7) 3.5, Message Type. I don't understand what "MUST >>>>> interoperate with other parties despite any differences" >>>>> means here and suspect that that 2119 MUST isn't doable. >>>> >>>> [PS:] Will reword these sentences. This is about disallowing >>> implementations to not interoperate with NEA complaints implements >>> since they always require a vendor specific attribute to be used to do >>> an assessment. >>> >>> And unfortunately I also don't understand your explanation >>> either;-) >> >> [PS:] Re-reading I can see why :). We're trying to avoid the situation where a vendor implements PT-TLS and claims to be compliant with the spec yet won't interoperate with other PT-TLS compliant implementations because they will only function after being given a vendor-specific attribute in the exchange. > > Ok, sounds like you really want to say "Implementations > MUST support foo,bar,baz featurs of this spec" somewhere. > But I guess see what re-wording seems to make sense to > you. > >>> >>>>> >>>>> (8) 3.5, 6.2 Any "reserved" values should really be >>>>> mentioned in the IANA considerations section so IANA don't >>>>> go and give them out, I mean the 0xffff... ones. "9+" is >>>>> also a bit odd in 6.2. You might want to change that to >>>>> specify the exact range "available for allocation by DE" >>>>> (or whatever is the right term) different from the >>>>> "reserved" value(s) there. >>>> >>>> [PS:] Agreed will describe the 0xffff... situation in the IANA >>> considerations and make the 9+ into a to be assigned range. >>> >>> Ack. >>> >>>>> >>>>> (9) 3.6, is it really ok for the "TLS session initiator" to >>>>> always be the one who proposes the versions in the version >>>>> request message? You still allow the NEA server to be the >>>>> TLS session initiator so what'd happen with this then is >>>>> confusing - the naughty client could get to pick the >>>>> weakest version of PT-TLS that the server supports? 3.7 >>>>> also seems to contradict this, saying that the "PT-TLS >>>>> initiator" sends the version request. Maybe there is some >>>>> cleaning up needed here? >>>> >>>> [PS:] The TLS session initiator offers a range of supported versions >>> and the responder selects one to use. If an initiator believe a >>> version to be weak it shouldn't offer it in the range. However if the >>> initiator considers several versions to be acceptable it can offer them. >>> Right now we only have 1 version but if for some reason 1.0 is badly >>> broken and 1.1 comes out with the fix, then initiators just offer 1.1. >>>> >>>>> >>>>> (10) 4.1, are you saying here that if any of these trust >>>>> relationships do not hold, then PT-TLS ought not be used? >>>>> If so, then saying that explicitly would be good. For >>>>> example, it could be that with some implementations, e.g. >>>>> that use less secure inter-proces communications, a bad >>>>> process on a client could invalidate some of these >>>>> assumptions, thus (maybe) making PT-TLS unsafe. >>>> >>>> [PS:] Will try to make this a little more clear. Other >>> countermeasures could be used if something in the trust model doesn't >>> hold for an implementation/deployment. >>> >>> I don't get your response addresses the question sorry. >> >> [PS:] Yes, I was agreeing with your comment and mentioning that the customer could have other mitigating controls or countermeasures that would still allow PT-TLS to be used. > > Ah. Gotcha. Sounds fine. > >>> >>>>> >>>>> (11) section 5: do you mean the NEA client SHOULD (in 2119 >>>>> terms) provide an indication here? If not, why not? If so, >>>>> what's the criteria for not providing that? (Perhaps if >>>>> there is no UI?) Same should/SHOULD question for the last >>>>> paragraph, i.e. s/should ensure/SHOULD ensure/ and what's >>>>> the exception? >>>> >>>> [PS:] Will change the SHOULDs. >>> >>> Ok. I'll look at the results of whatever change you mean:-) >> >> [PS:] will change the "should" to "SHOULD" as you suggested if the software has a UI. > > Ok > >>> >>>>> >>>>> (12) section 6: some of the intro text here is not really >>>>> for IANA, should it be moved elsewhere? (Mainly the >>>>> explanation of PEN handling, which might go up into 3.5 >>>>> perhaps?) >>>> >>>> [PS:] It was provided to provide context to the IANA on how the PEN >>> is defining different name spaces since this will be visible in the >>> repository. The text is also discussed elsewhere in the document where >>> implementers will see it. This is the same text used in the other NEA >>> RFCs. >>> >>> Ok. You may get other AD comments on this later but >>> we'll deal with 'em as they come. >> >> [PS:] Ok. I don't recall PA or PB receiving IESG comments about this text but that was a few years ago. >> >>> >>>>> >>>>> (13) section 6.1: you're asking IANA to act as a repository >>>>> for non-RFC specifications (sort-of), I think that's maybe >>>>> an innovation (not sure) that should be checked out with >>>>> IANA, or maybe you've done that or know of a precedent? >>>> >>>> [PS:] The IANA would just reference the permanent and readily >>> available specification in the repository even if it's not an IETF >>> document. I believe this was done in other NEA RFCs. >>> >>> This is the text I meant: >>> >>> "However, in this latter >>> case, the vendor MUST supply a copy to the IANA and authorize >>> the IANA to archive this copy and make it freely available to >>> all if at some point the document becomes no longer freely >>> available to all through other channels." >>> >>> That's more than referencing, isn't it? But yes, its in >>> RFC 5793 all right, so leave it as is. >>> >>>>> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that >>>>> entries with PEN value 0 need to be IETF stream RFCs, >>>>> or standards-track RFCs, or just RFCs or what? If you >>>>> want the DE to be able to add PEN=0 entries without >>>>> an RFC, I think saying that would be best. >>>> >>>> [PS:] We are following the RFC 5226 policies of "Specification >>> Required" which says a >>>> "permanent and readily available" document must be defined. This >>> doesn't need to be an RFC. This was thoroughly discussed by the WG in >>> the past and agreed to for previous NEA RFCs. >>> >>> But earlier (3.5) it said: >>> >>> If the PT-TLS Message Type Vendor ID field has the value zero >>> (0), then the PT-TLS Message Type field contains an IETF Standard >>> PT-TLS Message Type, as listed in the IANA registry. >>> >>> "IETF standard" != "specification required" so the question stands. >>> (Could be that previous NEA RFCs contain this ambiguity, if it is >>> one. That would not mean we shouldn't fix it here.) >> >> [PS:] Good point, maybe that should say "IETF namespace" instead of "IETF standard". > > Well, I guess its just a matter of getting whatever is > the intent written down precisely, which can sometimes > show up some ambiguity in the intent:-) > > The question here is does the specification required rule > apply to the addition of new entries with PEN=0? If yes, > then that's not an IETF namespace either since TCG or > whoever could do that. If no, then what rule does apply? > >> >>> >>>>> (15) References: can we not make the reference to 4346 (TLS >>>>> 1.1) informative and craft language to make that work? E.g. >>>>> say you SHOULD support TLS1.2 but that in reality a lot of >>>>> people still don't and are only doing 4346 as of now? I >>>>> think if you do that you can argue that TLS 1.1 is not >>>>> a normative reference and that'd be better in future once >>>>> most everyone has caught up with TLS1.2. >>>> >>>> [PS:] We discussed this a couple times in the working group and this >>> was the suggested approach due to the lack of 1.2 implementations. We >>> need to have a MUST and it seems premature to have that be 1.2 as it >>> might hold up implementations. This represents the working group >>> consensus. Hopefully the downgraded reference isn't a show stopper for >>> the IESG. >>> >>> I get the concern but don't think this is quite the right >>> approach. >>> >>> OAuth had the same concern and their solution might be on >>> to copy. [1] >>> >>> [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-1.6 >> >> [PS:] I don't have a problem with doing something more like this but of course it means we wouldn't have a MUST implement version of TLS which could cause interop issues. Any objections to going this route? > > Yep, its weasel words regardless. Weasel words with precedent > are probably better, much though I don't like 'em. (Note that > the WG decision here is sensible, but unfortunate.) > >>>> [PS:] If you are ok with the above responses, I'd be happy to put out >>> another revision early next week so the document can continue to make >>> progress. >>> >>> Almost all will be fine, might need a bit more chatting on >>> a few. Your call if you wanna iterate those some more via email >>> or draft revision(s). >>> >>> S >>> >>>> Thanks, >>>> Paul >>>> >> >> > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > > From Paul_Sangster@symantec.com Tue May 29 13:16:36 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7C911E8168 for ; Tue, 29 May 2012 13:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.566 X-Spam-Level: X-Spam-Status: No, score=-5.566 tagged_above=-999 required=5 tests=[AWL=1.033, BAYES_00=-2.599, 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 dTTxfqnF0bgc for ; Tue, 29 May 2012 13:16:35 -0700 (PDT) Received: from tus1smtoutpex01.symantec.com (tus1smtoutpex01.symantec.com [216.10.195.241]) by ietfa.amsl.com (Postfix) with ESMTP id 296E511E8088 for ; Tue, 29 May 2012 13:16:30 -0700 (PDT) X-AuditID: d80ac3f1-b7f936d0000075bb-7a-4fc52e9db0ac Received: from tus1smtintpin02.ges.symantec.com (TUS1SMTINTPIN02.ges.symantec.com [192.168.215.102]) by tus1smtoutpex01.symantec.com (Symantec Brightmail Gateway out) with SMTP id 7D.D2.30139.D9E25CF4; Tue, 29 May 2012 20:16:29 +0000 (GMT) Received: from [155.64.220.139] (helo=TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM) by tus1smtintpin02.ges.symantec.com with esmtp (Exim 4.76) (envelope-from ) id 1SZSpZ-0004vG-Hm; Tue, 29 May 2012 20:15:49 +0000 Received: from TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM ([155.64.220.150]) by TUS1XCHHUBPIN03.SYMC.SYMANTEC.COM ([155.64.220.139]) with mapi; Tue, 29 May 2012 13:16:29 -0700 From: Paul Sangster To: Stephen Farrell , "nea@ietf.org" Date: Tue, 29 May 2012 13:16:30 -0700 Thread-Topic: [Nea] AD review of draft-ietf-nea-pt-tls-04 Thread-Index: Ac09hR2ie275OgRhQ/Oqw6SJBbxexQAUMexQ Message-ID: <6E79D623502C70419A9EAB18E4D274252B8A49D524@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> References: <4FB4EA34.2020104@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B8861BF65@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FC0FC8A.5030708@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B8861BFA5@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FC2A75C.2000701@cs.tcd.ie> <4FC4A3A6.6050803@cs.tcd.ie> In-Reply-To: <4FC4A3A6.6050803@cs.tcd.ie> 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+NgFupnkeLIzCtJLcpLzFFi42I5sOJ6mu5cvaP+Bi0HxS0+v62wmL73GrsD k8fa7qtsHkuW/GQKYIrisklJzcksSy3St0vgyni48hhrwVu5igc/H7M2MLZKdDFyckgImEhc f3KVFcIWk7hwbz1bFyMXh5DAR0aJ6SeesUM4rxkl2ppeQDmrGCWO7JoA1sImYCCx88gpoAQH h4iAn8T/2T4gYRYBVYkDF6YwgdjCAhYStxYsZgSxRQQsJY5c+sQCYRtJPJp3mgmklVcgSuLb 1wyI8c+ZJCavnccOUsMpoClxt3MfG4jNCHTd91NrwGYyC4hL3HoynwniagGJJXvOM0PYohIv H/9jhagXlbjTvp4Rol5HYsHuT2wQtrbEsoWvwep5BQQlTs58wjKBUWwWkrGzkLTMQtIyC0nL AkaWVYwyJaXFhsW5JfmlJQWpFQaGesWVuYnASErWS87P3cQIjKYbXIc/7mC8vlTxEKMAB6MS D2/9ryP+QqyJZUCVhxglOJiVRHgFs4BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEed/v3uovJJCe WJKanZpakFoEk2Xi4JRqYOxxWBCZ2L7h6ttU+e9LNjivLGLWzxT1f3Pxts7ybzlJFRFfpZeJ Nt15uiqB44S4ontekj/ngTsbul/sswpe0crhaDnBrKRo14dtuzKlGnpWlvmZeGsKn0k1VvkW LrrYQ7TIpGaJX3xnQGYC14+Flz1kKpcYLF14gO3Jr8XTuKY6rhUSUj3+R4mlOCPRUIu5qDgR ACxsDQ+iAgAA Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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, 29 May 2012 20:16:36 -0000 I'll work to get out an revision ASAP. Just a final comment on the thread = below... > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, May 29, 2012 3:24 AM > To: nea@ietf.org > Cc: Paul Sangster > Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 >=20 > =20 > >> > >>> > >>>>> > >>>>> (13) section 6.1: you're asking IANA to act as a repository > >>>>> for non-RFC specifications (sort-of), I think that's maybe > >>>>> an innovation (not sure) that should be checked out with > >>>>> IANA, or maybe you've done that or know of a precedent? > >>>> > >>>> [PS:] The IANA would just reference the permanent and readily > >>> available specification in the repository even if it's not an IETF > >>> document. I believe this was done in other NEA RFCs. > >>> > >>> This is the text I meant: > >>> > >>> "However, in this latter > >>> case, the vendor MUST supply a copy to the IANA and authorize > >>> the IANA to archive this copy and make it freely available to > >>> all if at some point the document becomes no longer freely > >>> available to all through other channels." > >>> > >>> That's more than referencing, isn't it? But yes, its in > >>> RFC 5793 all right, so leave it as is. > >>> > >>>>> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that > >>>>> entries with PEN value 0 need to be IETF stream RFCs, > >>>>> or standards-track RFCs, or just RFCs or what? If you > >>>>> want the DE to be able to add PEN=3D0 entries without > >>>>> an RFC, I think saying that would be best. > >>>> > >>>> [PS:] We are following the RFC 5226 policies of "Specification > >>> Required" which says a > >>>> "permanent and readily available" document must be defined. This > >>> doesn't need to be an RFC. This was thoroughly discussed by the WG > in > >>> the past and agreed to for previous NEA RFCs. > >>> > >>> But earlier (3.5) it said: > >>> > >>> If the PT-TLS Message Type Vendor ID field has the value zero > >>> (0), then the PT-TLS Message Type field contains an IETF > Standard > >>> PT-TLS Message Type, as listed in the IANA registry. > >>> > >>> "IETF standard" !=3D "specification required" so the question stands. > >>> (Could be that previous NEA RFCs contain this ambiguity, if it is > >>> one. That would not mean we shouldn't fix it here.) > >> > >> [PS:] Good point, maybe that should say "IETF namespace" instead of > "IETF standard". > > > > Well, I guess its just a matter of getting whatever is > > the intent written down precisely, which can sometimes > > show up some ambiguity in the intent:-) [PS:] PA-TNC RFC did a little more complete job of explaining the namespace= intentions. Please take a look at RFC 5792 sections 2.1 and 2.2 and let u= s know whether you think those should be referenced (or duplicated in) PT-T= LS. The approach we're discussing is used by both PA-TNC and PB-TNC. > > > > The question here is does the specification required rule > > apply to the addition of new entries with PEN=3D0? If yes, > > then that's not an IETF namespace either since TCG or > > whoever could do that. If no, then what rule does apply? > > [PS:] "For all of the IANA registries defined by this specification, new va= lues are added to the registry by Expert Review with Specification Required= , using the Designated Expert process defined in RFC 5226 [RFC5226]." =20 If it helps we can stop referring the PT-TLS PEN=3D0 namespace as "IETF sta= ndard" and just informally call it the IETF's namespace since values using = this namespace will at least have been expert reviewed in the IETF. >=20 > >>> > >>>> Thanks, > >>>> Paul > >>>> > >> > >> > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www.ietf.org/mailman/listinfo/nea > > > > From stephen.farrell@cs.tcd.ie Tue May 29 14:03:43 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC6811E8074 for ; Tue, 29 May 2012 14:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.005 X-Spam-Level: X-Spam-Status: No, score=-102.005 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599, 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 xIIdLo9IFlvq for ; Tue, 29 May 2012 14:03:41 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB3421F864E for ; Tue, 29 May 2012 14:03:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C0986153947; Tue, 29 May 2012 22:03:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338325417; bh=SVOwdiiD451jlX oduwaTSannZIJA22wJeAqUvuGQrzQ=; b=FloolzmLgvMBFcwYGGlvBwhO6DQ4GA nXCSnULex71M0ZLJHU8yJmi4Lul0FZumu2V68XQaDUc178XL0YfhUT0o2mps6iff PU5u8WMvEZJbGjnj8RwWYVUzFF3eM88pPovvJaQpfa+G3QS2NrULvGnZtCOymZrf 5ulfRvcQOXMuU3J4Q7Y4jHl5qt4SdL1FKkNgxw+MwHt/tOT/w3GCkPSwquO+zCk+ KNE74hZuTZNyU8sW9wDY9Iy05oRuTGAjfQ5vtG4aQe3GRmmCJfDARfSjB1EEq5El 2eDIoABkkRLXiQPUAXhb8al1va52gUfJkn5+9XDVH+bM8Z+4u1XER3Zg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id X49Mb-teNHtk; Tue, 29 May 2012 22:03:37 +0100 (IST) Received: from [10.87.48.8] (unknown [86.41.8.23]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 259BD153975; Tue, 29 May 2012 22:03:36 +0100 (IST) Message-ID: <4FC539A8.9080809@cs.tcd.ie> Date: Tue, 29 May 2012 22:03:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Paul Sangster References: <4FB4EA34.2020104@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B8861BF65@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FC0FC8A.5030708@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B8861BFA5@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> <4FC2A75C.2000701@cs.tcd.ie> <4FC4A3A6.6050803@cs.tcd.ie> <6E79D623502C70419A9EAB18E4D274252B8A49D524@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> In-Reply-To: <6E79D623502C70419A9EAB18E4D274252B8A49D524@TUS1XCHEVSPIN35.SYMC.SYMANTEC.COM> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nea@ietf.org" Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 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, 29 May 2012 21:03:43 -0000 Hiya, On 05/29/2012 09:16 PM, Paul Sangster wrote: > I'll work to get out an revision ASAP. Just a final comment on the thread below... > >> -----Original Message----- >> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >> Sent: Tuesday, May 29, 2012 3:24 AM >> To: nea@ietf.org >> Cc: Paul Sangster >> Subject: Re: [Nea] AD review of draft-ietf-nea-pt-tls-04 >> >> > > > >>>> >>>>> >>>>>>> >>>>>>> (13) section 6.1: you're asking IANA to act as a repository >>>>>>> for non-RFC specifications (sort-of), I think that's maybe >>>>>>> an innovation (not sure) that should be checked out with >>>>>>> IANA, or maybe you've done that or know of a precedent? >>>>>> >>>>>> [PS:] The IANA would just reference the permanent and readily >>>>> available specification in the repository even if it's not an IETF >>>>> document. I believe this was done in other NEA RFCs. >>>>> >>>>> This is the text I meant: >>>>> >>>>> "However, in this latter >>>>> case, the vendor MUST supply a copy to the IANA and authorize >>>>> the IANA to archive this copy and make it freely available to >>>>> all if at some point the document becomes no longer freely >>>>> available to all through other channels." >>>>> >>>>> That's more than referencing, isn't it? But yes, its in >>>>> RFC 5793 all right, so leave it as is. >>>>> >>>>>>> (14) 6.2 & 6.3 - do you need to tell IANA or the DE that >>>>>>> entries with PEN value 0 need to be IETF stream RFCs, >>>>>>> or standards-track RFCs, or just RFCs or what? If you >>>>>>> want the DE to be able to add PEN=0 entries without >>>>>>> an RFC, I think saying that would be best. >>>>>> >>>>>> [PS:] We are following the RFC 5226 policies of "Specification >>>>> Required" which says a >>>>>> "permanent and readily available" document must be defined. This >>>>> doesn't need to be an RFC. This was thoroughly discussed by the WG >> in >>>>> the past and agreed to for previous NEA RFCs. >>>>> >>>>> But earlier (3.5) it said: >>>>> >>>>> If the PT-TLS Message Type Vendor ID field has the value zero >>>>> (0), then the PT-TLS Message Type field contains an IETF >> Standard >>>>> PT-TLS Message Type, as listed in the IANA registry. >>>>> >>>>> "IETF standard" != "specification required" so the question stands. >>>>> (Could be that previous NEA RFCs contain this ambiguity, if it is >>>>> one. That would not mean we shouldn't fix it here.) >>>> >>>> [PS:] Good point, maybe that should say "IETF namespace" instead of >> "IETF standard". >>> >>> Well, I guess its just a matter of getting whatever is >>> the intent written down precisely, which can sometimes >>> show up some ambiguity in the intent:-) > > [PS:] PA-TNC RFC did a little more complete job of explaining the namespace intentions. Please take a look at RFC 5792 sections 2.1 and 2.2 and let us know whether you think those should be referenced (or duplicated in) PT-TLS. The approach we're discussing is used by both PA-TNC and PB-TNC. Aha! Precedent is enough to be going on with:-) Maybe just stick with what you have and refer back to that saying "same as there." >>> >>> The question here is does the specification required rule >>> apply to the addition of new entries with PEN=0? If yes, >>> then that's not an IETF namespace either since TCG or >>> whoever could do that. If no, then what rule does apply? >>> > > [PS:] "For all of the IANA registries defined by this specification, new values are added to the registry by Expert Review with Specification Required, using the Designated Expert process defined in RFC 5226 [RFC5226]." > > If it helps we can stop referring the PT-TLS PEN=0 namespace as "IETF standard" and just informally call it the IETF's namespace since values using this namespace will at least have been expert reviewed in the IETF. Not saying "IETF standard" would have been better but if its it other NEA RFCs then probably as well to stick with it. Maybe add an explanatory sentence. Cheers, S. >> > > > >>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>> >>>> >>> _______________________________________________ >>> Nea mailing list >>> Nea@ietf.org >>> https://www.ietf.org/mailman/listinfo/nea >>> >>> From internet-drafts@ietf.org Tue May 29 18:55:44 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7BC11E80E1; Tue, 29 May 2012 18:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, 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 PDEM4Krh198g; Tue, 29 May 2012 18:55:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A85621F8595; Tue, 29 May 2012 18:55:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120530015543.1819.73199.idtracker@ietfa.amsl.com> Date: Tue, 29 May 2012 18:55:43 -0700 Cc: nea@ietf.org Subject: [Nea] I-D Action: draft-ietf-nea-pt-tls-05.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 01:55:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Network Endpoint Assessment Working G= roup of the IETF. Title : PT-TLS: A TCP-based Posture Transport (PT) Protocol Author(s) : Paul Sangster Nancy Cam-Winget Joseph Salowey Filename : draft-ietf-nea-pt-tls-05.txt Pages : 44 Date : 2012-05-29 This document specifies PT-TLS, a TCP-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ From stephen.farrell@cs.tcd.ie Wed May 30 01:56:22 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D313821F86D7 for ; Wed, 30 May 2012 01:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, 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 4Gxdky8nSXKH for ; Wed, 30 May 2012 01:56:21 -0700 (PDT) Received: from scss.tcd.ie (hermes.scss.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8296121F8656 for ; Wed, 30 May 2012 01:56:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id F2D7B171479 for ; Wed, 30 May 2012 09:56:17 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1338368177; bh=9+WRypI8FBvbGX FE6RAHjt3nOGC0TXVlkmyzoQxeXlY=; b=EMaVPcoFlBGrdHIk3rwUaZBSdIVEM6 0LnE0/8N9lV+T4nznHrVfrliZl4HD+5z52gaf63R1psMZ8zGznsUSv6/ElIckx/5 37H/cqR9HgVAcXXiSxtAkvP8dj79Z1Fggk2cRaEjwKbyo83wm+z0mq6Kt6UP+L05 /dMkvN0Du75RHSXrVb5c4ZBZHZpUPawnixYIDrcL0D/QXW/OTAU7JiQNHLPzGCVY CaFpPlc25o4vpxXWsuPunsULYZBC7Ogxhr5TGYO/KuFP5a5+0K6iBsMfGRpl0vWz dakH3QyfJpzhCmZMrZx31VuQDTXhKWZY2JjMHEa64d0yVGoK5AeJpOgg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 0q1ANSLeBGkD for ; Wed, 30 May 2012 09:56:17 +0100 (IST) Received: from [IPv6:2001:770:10:203:d81a:2c3f:f05e:344f] (unknown [IPv6:2001:770:10:203:d81a:2c3f:f05e:344f]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 5CA6A171476 for ; Wed, 30 May 2012 09:56:17 +0100 (IST) Message-ID: <4FC5E0B1.5060907@cs.tcd.ie> Date: Wed, 30 May 2012 09:56:17 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: nea@ietf.org References: <20120530015543.1819.73199.idtracker@ietfa.amsl.com> In-Reply-To: <20120530015543.1819.73199.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Nea] I-D Action: draft-ietf-nea-pt-tls-05.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 08:56:23 -0000 Thanks for the quick turnaround of my AD review comments. I've requested IETF LC for this, the announce message should pop out later today. Cheers, S. On 05/30/2012 02:55 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Endpoint Assessment Working Group of the IETF. > > Title : PT-TLS: A TCP-based Posture Transport (PT) Protocol > Author(s) : Paul Sangster > Nancy Cam-Winget > Joseph Salowey > Filename : draft-ietf-nea-pt-tls-05.txt > Pages : 44 > Date : 2012-05-29 > > This document specifies PT-TLS, a TCP-based Posture Transport (PT) > protocol. The PT-TLS protocol carries the Network Endpoint > Assessment (NEA) message exchange under the protection of a Transport > Layer Security (TLS) secured tunnel. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-nea-pt-tls-05.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www.ietf.org/mailman/listinfo/nea > > From iesg-secretary@ietf.org Wed May 30 07:16:33 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A565221F867B; Wed, 30 May 2012 07:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, 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 k443B4BAVWw5; Wed, 30 May 2012 07:16:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3326421F8663; Wed, 30 May 2012 07:16:33 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120530141633.22553.12004.idtracker@ietfa.amsl.com> Date: Wed, 30 May 2012 07:16:33 -0700 Cc: nea@ietf.org Subject: [Nea] Last Call: (PT-TLS: A TCP-based Posture Transport (PT) Protocol) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 14:16:33 -0000 The IESG has received a request from the Network Endpoint Assessment WG (nea) to consider the following document: - 'PT-TLS: A TCP-based Posture Transport (PT) Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-06-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies PT-TLS, a TCP-based Posture Transport (PT) protocol. The PT-TLS protocol carries the Network Endpoint Assessment (NEA) message exchange under the protection of a Transport Layer Security (TLS) secured tunnel. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-nea-pt-tls/ballot/ No IPR declarations have been submitted directly on this I-D. From latze@angry-red-pla.net Thu May 31 07:43:36 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739D621F8704 for ; Thu, 31 May 2012 07:43:36 -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 kx5SVgIopYBE for ; Thu, 31 May 2012 07:43:35 -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 17E0B21F86FA for ; Thu, 31 May 2012 07:43:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=thuvia.angry-red-pla.net) by thuvia.angry-red-pla.net with esmtp (Exim 4.69) (envelope-from ) id 1Sa6b6-0006HU-Dp; Thu, 31 May 2012 16:43:32 +0200 Received: from 193.5.238.18 (SquirrelMail authenticated user latze) by thuvia.angry-red-pla.net with HTTP; Thu, 31 May 2012 16:43:32 +0200 (CEST) Message-ID: <6ac79e934d4afb5a3ae7a954f613c135.squirrel@thuvia.angry-red-pla.net> In-Reply-To: <05D091D3-7810-4B51-BB09-64D126F99E80@cisco.com> References: <4FA3C664.4000208@angry-red-pla.net> <05D091D3-7810-4B51-BB09-64D126F99E80@cisco.com> Date: Thu, 31 May 2012 16:43:32 +0200 (CEST) From: latze@angry-red-pla.net To: "Joe Salowey" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: nea@ietf.org Subject: Re: [Nea] WGLC on NEA Asokan Attack Analysis X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 14:43:36 -0000 Hi Joe, sorry for the late reply. I somehow missed your mail. I like the text you proposed. That is more clear for me. Regards Carolin > Hi Carolin, > > PT-TLS and PT-EAP implement mechanism to enforce both cryptographic > binding and identity. They do not implement all the possible mechanisms > for cryptographic binding because that would be a bit redundant. Here is > an attempt at some better text: > > "The PT-TLS [5] and PT-EAP [6] protocols developed by the NEA working > group include mechanisms that can provide cryptographic binding and > identity binding countermeasures." > > Cheers, > > Joe > > > On May 4, 2012, at 5:07 AM, Carolin Latze wrote: > >> Hi >> >> I have just one comment. In the introduction it is said that "The NEA WG >> has included several of these countermeasures in PT-TLS [5] and PT-EAP >> [6]" The first question that came into my mind was "and why not all of >> them?" :-) So maybe it would make sense to describe the reasoning behind >> the selection of the countermeasures that will be used in PT-TLS and >> PT-EAP. >> >> regards >> Carolin >> >> On 04/27/2012 04:58 PM, Stephen Hanna wrote: >>> As previously agreed, the NEA Asokan Attack Analysis >>> has been changed into a NEA WG draft. This draft has >>> received several years of discussion and review in >>> our WG, dating back to its initial publication as >>> draft-salowey-nea-asokan-00.txt back in October 2010. >>> >>> We agreed to make this document a WG draft because >>> we found its analysis essential to describing the need >>> for TLS channel bindings to prevent Asokan attacks. >>> Both PT-TLS and PT-EAP contain informational but >>> important references to this document. For those >>> documents to be fully understood, it's essential >>> for the NEA Asokan Attack Analysis to become an >>> informational RFC. >>> >>> Therefore, I'd like to ask all active NEA WG >>> participants to please review the latest draft >>> of the NEA Asokan Attack Analysis and to send >>> comments, corrections, or questions to the WG >>> list. Please complete this Working Group Last >>> Call review within two weeks (by 1600 GMT on >>> Friday, May 11 - noon EDT or 9 AM PDT). If any >>> substantive issues have been raised, we'll get >>> those resolved. And if there's WG consensus to >>> ask the IESG to advance the document to >>> Informational RFC status, we'll do that. >>> >>> If you don't have any comments on the document >>> but you agree that it should advance to >>> Informational RFC status, you can just send >>> an email in response to this one saying so. >>> And if you think that it should not advance, >>> please send an email saying that also. These >>> emails will be useful in judging WG consensus. >>> >>> Here's a link to the draft for review: >>> >>> http://datatracker.ietf.org/doc/draft-ietf-nea-asokan/ >>> >>> At only eight pages in length (and really only >>> four pages of content), I think you will find it >>> an easy but interesting read. In any event, you >>> should learn something. And something quite >>> relevant to NEA. If you've already read the >>> document before, a quick skim should help you >>> confirm that you're comfortable with the latest >>> version (or not). Your brief review and comment >>> would be greatly appreciated. >>> >>> Thanks in advance for your help, >>> >>> 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 > > From cliffordk@juniper.net Thu May 31 12:32:32 2012 Return-Path: X-Original-To: nea@ietfa.amsl.com Delivered-To: nea@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D96721F86A2 for ; Thu, 31 May 2012 12:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LPVOXDoXiYoq for ; Thu, 31 May 2012 12:32:31 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with ESMTP id 01FA521F869E for ; Thu, 31 May 2012 12:32:30 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKT8fHTiAgtvD6pvJttEdT3FX58CbE80lS@postini.com; Thu, 31 May 2012 12:32:31 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 31 May 2012 12:30:39 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 31 May 2012 15:30:38 -0400 From: Clifford Kahn To: Joe Salowey Date: Thu, 31 May 2012 15:30:36 -0400 Thread-Topic: [Nea] Review comments on Asokan Attack Analysis Thread-Index: Ac00XhWGETptJhfqSVOUQr8Kdjq2jQLBXuGg Message-ID: References: <258BE838-59F8-441F-ABE7-172A8F1B03FF@cisco.com> In-Reply-To: <258BE838-59F8-441F-ABE7-172A8F1B03FF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nea@ietf.org" Subject: Re: [Nea] Review comments on Asokan Attack Analysis X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 19:32:32 -0000 Hi Joe. =20 It all sounds good. (Steve Hanna tells me that the protocol is to say so e= xplicitly; sorry if I held up the works!) Thanks Cliff -----Original Message----- From: Joe Salowey [mailto:jsalowey@cisco.com]=20 Sent: Thursday, May 17, 2012 2:52 PM To: Clifford Kahn Cc: nea@ietf.org Subject: Re: [Nea] Review comments on Asokan Attack Analysis On May 2, 2012, at 12:30 PM, Clifford Kahn wrote: > Hi Joe. >=20 >> Thanks for taking time to review the document and provide good comments. >=20 > Glad to help. >=20 >> On Apr 28, 2012, at 8:36 PM, Clifford Kahn wrote: >=20 >> =D8 The recommendations for addressing the NEA Asokan Attack are as fol= lows: >>=20 >> To whom are these recommendations? To implementers, or to writers of sp= ecs? =20 >>=20 >=20 > [Joe] Mostly to writers of specs, but it should also help implementers un= derstand the motivation behind the specification.=20 >=20 > [Cliff] That makes sense. So the recommendations are for protocols. The = recommendations in most IETF specs are for implementations of protocols, wh= ich is a little bit different. It may help to reword each recommendation s= omething like: "Protocols should make use of cryptographic binding ..." >=20 >=20 [Joe] OK, sounds good.=20 >> =D8 1. Make use of cryptographic binding, however binding identities of= the tunnel endpoints in the EMA may be useful. >>=20 >> The "however" is confusing. I think it means that one should make use o= f cryptographic binding, and that in addition binding identities of the tun= nel endpoints in the EMA may be useful. Whether I got it right or not, ple= ase consider rephrasing. >=20 > [Joe] Good catch, this should be reworded and the bit about the tunnel id= entities should be removed. How about: >=20 > "Make use of cryptographic binding to protect the integrity of the TLS tu= nnel. "=20 >=20 > [Cliff] That works for me. >=20 >>=20 >> =D8 2. Use the same mechanism in L2 and L3 PT transports that make use = of TLS (e.g. PT-TLS and PT-EAP). >>=20 >> I take it that "the same mechanism" refers to the two mechanisms in reco= mmendation 1. But will others take it that way?=20 >>=20 >> Doesn't recommendation 1 entail recommendation 2? Why is 2 here? Since= 2 is here, I take it that 1 must have in mind transports other than the on= es 2 mentions. But 1 doesn't say what transports it has in mind - or I don= 't understand. >>=20 >=20 > [Joe] How about: >=20 > "Use the same cryptographic binding mechanism in L2 and L3 TLS-based PT t= ransports (e.g. PT-TLS and PT-EAP)." >=20 > [Cliff] I don't think that helps me. Sorry to be thick. Doesn't recomme= ndation 1 cover all transports? Isn't recommendation 2 a corollary and red= undant? =20 >=20 > If recommendation 1 does not cover all transports, I suggest making it sa= y which transports it covers. If recommendation 1 does cover all transport= s and recommendation 2 is a corollary, you might either delete recommendati= on 2 or make recommendation 2 begin "In particular": >=20 > "In particular, L2 and L3 TLS-based PT transports ... should use cryptog= raphic binding ..." =20 >=20 > That would clear up the relationship between recommendations 1 and 2.=20 >=20 [Joe] I like the second suggestion a little better. How about: "2. In particular, L2 and L3 TLS-based PT transports (e.g. PT-TLS and PT-EA= P) should use the same cryptographic binding mechanism" >=20 >> =D8 3. Neither TLS endpoint can be in sole control of the TLS pre-maste= r secret. This is not strictly necessary when tls-unique channel binding v= alues are used. >>=20 >> I'm a bit confused by the double negative. The first sentence is a nega= tive, and the second negates that negative.=20 >>=20 >> I think it means that when TLS-unique channel binding values are used, i= t's kind of OK for one TLS endpoint to be in sole control of the TLS pre-ma= ster secret. Whether I got it right or not, please consider rephrasing. >>=20 >=20 > [Joe] Yes, that is correct. The text is a bit confusing and unnecessary= since we recommend use of TLS unique, I think we should delete this item. = we could add to 4: >=20 > "The preferred approach is to use the tls-unique channel binding data fro= m RFC 5929 [9]. The tls-unique value will be made available to the EMA tha= t will use it. This approach can utilize any TLS cipher suite based on a = strong cipher algorithm." >=20 > (perhaps this just opens the can of worms of what a strong cipher algorit= hm is.) >=20 > [Cliff] I like the simplification and the clarity. >=20 > If one's cipher suite is not strong enough and an attacker cracks it, the= n all bets are off. That's always true. I don't see why a strong cipher s= uite is more needed here than it is in other places. If you agree with tha= t, you might want to delete "based on a strong cipher algorithm". =20 >=20 [Joe] I agree. =20 > Thanks for considering my comments. > Cliff >=20 >>=20 >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www.ietf.org/mailman/listinfo/nea >=20