Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-06

Sam Hartman <> Thu, 27 May 2010 18:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B676A3A6848 for <>; Thu, 27 May 2010 11:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.47
X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=-0.805, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C0dTtdKkgrnu for <>; Thu, 27 May 2010 11:31:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 45ED63A690E for <>; Thu, 27 May 2010 11:31:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by (Postfix) with ESMTPS id 0CF2F201B2; Thu, 27 May 2010 14:31:18 -0400 (EDT)
Received: by (Postfix, from userid 8042) id 0518D43EF; Thu, 27 May 2010 14:30:47 -0400 (EDT)
From: Sam Hartman <>
To: Yaron Sheffer <>
References: <> <>
Date: Thu, 27 May 2010 14:30:47 -0400
In-Reply-To: <> (Yaron Sheffer's message of "Wed, 26 May 2010 15:21:15 +0300")
Message-ID: <>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-06
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 May 2010 18:31:33 -0000

>>>>> "Yaron" == Yaron Sheffer <> writes:

    Yaron> Hi Brian, thanks for your review. I accept all of your
    Yaron> comments, with the exception of the last one: I consider
    Yaron> channel binding as an important capability, which implies
    Yaron> that it needs to be provided in an interoperable
    Yaron> manner. There is no standard set of channel binding
    Yaron> properties yet, but I expect that eventually we will have
    Yaron> one.
    Yaron> presents one viable direction for doing that, and I have
    Yaron> asked the authors of that draft to add a section that
    Yaron> describes how their proposal can integrate with EAP-EKE. In
    Yaron> other words, the Channel Binding Value payload should not be
    Yaron> seen as a "vendor ID", but rather as a placeholder for a
    Yaron> standardized solution.

I've agreed to take over editorship of draft-ietf-emu-chbind.  My role
in this is part of a larger client engagement.  Currently, I'm schedule
to write up my understanding of some open issues with this document
including a discussion I had with Glenn at the last IETF in early June
and to get a new draft out by the cutoff.

One of the specific discussions that came up was the importance of
making sure we have a consistent strategy across EAP methods for
including channel binding values.  I'll be happy to take a look at EKE
when I take a look at other methods for the emu-chbind update.