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.