Re: [Nea] Results of Consensus check on EAP-based PT
Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 24 August 2011 22:41 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 B9D1A21F8C6B for <nea@ietfa.amsl.com>; Wed, 24 Aug 2011 15:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.099
X-Spam-Level:
X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 aJAVXy0mnOOI for <nea@ietfa.amsl.com>; Wed, 24 Aug 2011 15:41:20 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5E221F8B47 for <nea@ietf.org>; Wed, 24 Aug 2011 15:41:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D4F50171C5B; Wed, 24 Aug 2011 23:42:27 +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=1314225746; bh=bT/uqod8I/GazT EwLxanU9WH9uOOfnxpYU7/yvpgXCA=; b=ifexmF6lptyswq9qPzvU8tIs9cPWq+ +8qAmyXqCuznq0rZRcse4xhWh5Ndic8XRkynnsGqCnOswrcXcMGwsQitqqHtqUKM baUI6A19rxt026GEG7+1GAC+eX+qJtTDnf1WWNYDZjSWcnKoi/0Mu1BqEBB1+VlA 5qI9IpAd2brGbZBgMyEGW/63V3RdmMIBA4hH1KsXiZ1h8jxUomN15DDz8wBVD9WF YQFnRT6nwcW9hMtHTfwQXklXaaN1c5qHTZF4NotT/KezsZ7MpthaXocnUq1Cn0sY FgBqQZIv4xbNW7r3StJ/jJuDQIROmCakE/UWK1t2u+i4dv8SrRQAsVGw==
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 spyeXQpDh6nd; Wed, 24 Aug 2011 23:42:26 +0100 (IST)
Received: from [10.87.48.7] (unknown [86.46.30.197]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 41521171C1B; Wed, 24 Aug 2011 23:42:25 +0100 (IST)
Message-ID: <4E557E47.7040305@cs.tcd.ie>
Date: Wed, 24 Aug 2011 23:42:15 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Susan Thomson <sethomso@cisco.com>
References: <CA730BEE.14543%sethomso@cisco.com>
In-Reply-To: <CA730BEE.14543%sethomso@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: nea@ietf.org
Subject: Re: [Nea] Results of Consensus check on EAP-based PT
X-BeenThere: nea@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Endpoint Assessment discussion list <nea.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nea>, <mailto:nea-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nea>
List-Post: <mailto:nea@ietf.org>
List-Help: <mailto:nea-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nea>, <mailto:nea-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2011 22:41:20 -0000
Hi all, The requested decision is at the end, so you can skip there first if you're only keen on the outcome:-) Firstly, I entirely agree with the WG that picking one way to do this is the way to go - other WGs with which I've been involved have regretted standardising two ways to do the same thing for years afterwards, so thanks for being open to even a pretty unqualified selection process, (i.e. having me pick) - I think you're doing the right thing in pushing hard for one standard. I'd also like to thank the chairs for their leadership of what could have been a quite divisive discussion - they're either good at that or else you're all much more polite than the average set of IETF participants:-) Second, I also agree with the WG that basically either approach could work so there's not much difference here, and that's probably one of the reasons why its been hard to reach a decision. Third, I also agree with the chairs that there is no rough consensus in the WG, neither on the list nor at the last couple of face to face meetings. My own reading of the situation is that PT-EAP does provide a firmer basis on which to go forward at this stage, given that there are implementations that have been deployed that are very similar. That was also backed up by a few off-list responses I got from people who know more about this than I but who are not involved in the WG. When I asked which way they thought would be better, one said doing it in EAP is crazy for size reasons, but most (4 to 2) said that the running code should win. However, I also agree with the argument that EAP-TLV is more in line with the direction in which EAP standardisation has been going, i.e. avoiding new less-secure EAP method definitions. OTOH, there are so many existing EAP methods, that its hard to see this as a showstopper. The other thing that strikes me is that neither approach is yet fully baked, in particular, the WG will still need to figure the detail of how to handle requirement PT-2 from RFC 5209, copied below: "PT-2 The PT protocol MUST be capable of supporting mutual authentication, integrity, confidentiality, and replay protection of the PB messages between the Posture Transport Client and the Posture Transport Server." My feeling is that the two already-similar proposals might look even more similar when a solution meeting that requirement is developed in the WG. (That solution might involve just an EAP tunnel or maybe more.) And that might (or might not) lead to a change in the WG consensus depending on how that solution looks. If a change in the WG opinion did happen later on I don't believe that switching to TLVs would be that much work at that point (as otherwise the WG consensus would presumably not be for change), so even if a change were done later I don't see it adding much delay. But of course, we don't want to get wedged again on a lack of consensus. So, taking all the above into account, I propose the following: - Proceed with PT-EAP: make draft-hanna-nea-pt a WG draft, and develop that until its ready for WGLC - At WGLC time, if called upon to do so by a WG participant, the chairs are to hold a new consensus call to see if WG consensus has in fact moved to using TLVs rather than an EAP method, *but* with a default that no consensus for change to TLVs at that point means staying with the EAP method approach of PT-EAP Note that this does not call for the proponents of EAP-TLV to continue developing their approach independently. My hope is that they get involved with the WG document and then, when that's ready, make their argument for a change to TLVs again, if they still feel that's useful. Regards, Stephen.
- [Nea] Results of Consensus check on EAP-based PT Susan Thomson
- Re: [Nea] Results of Consensus check on EAP-based… Stephen Farrell