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

Yaron Sheffer <> Mon, 06 September 2010 17:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E25703A67B5 for <>; Mon, 6 Sep 2010 10:47:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.813
X-Spam-Status: No, score=-101.813 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P1oRETy9GDPA for <>; Mon, 6 Sep 2010 10:47:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id DBE0F3A6951 for <>; Mon, 6 Sep 2010 10:47:54 -0700 (PDT)
Received: by fxm18 with SMTP id 18so2978210fxm.31 for <>; Mon, 06 Sep 2010 10:48:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8budYuTRTnMrEHVH6oq5A+tuJO/8Aai2q/Bsxpve7Q0=; b=WaZYjG07At+q9zjQ8lgrwbP54W2lNicSUoEGErGjl9X3kacgeqkFtRNN7d/FKxFO5O f34mAufkfFGjYHqGC8iWZ6/4mzUMHqvv3CX7TX855jzJFqKzNMbSWyGhNgA+zQikLDQR CPCFw/xdAEg7HEJU78ONg4G1DyfUNj4cVCiRM=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=j9u8nI/dU7E2VxJUkvhnRx/1KNh6PK3kx2HDlayOi6VpPN3SC2NFiTC8533PcKe1+Z krzajaldHt4Byid64+Upy9H7HfcRfq/s0K47aUsxAmKIgAlvTnimV9q1wr9DQXeZD2wl EqP6vNmL1GW7Wbtqyw08IVd1rYcVWTnQ3VNZY=
Received: by with SMTP id r4mr2958619fap.56.1283795302441; Mon, 06 Sep 2010 10:48:22 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id s20sm2434629faa.28.2010. (version=SSLv3 cipher=RC4-MD5); Mon, 06 Sep 2010 10:48:21 -0700 (PDT)
Message-ID: <>
Date: Mon, 06 Sep 2010 20:48:13 +0300
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6
MIME-Version: 1.0
To: Brian Weis <>, Dan Harkins <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Tim Polk <>,,
Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07
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: Mon, 06 Sep 2010 17:47:57 -0000

Hi Brian, Dan,

thanks for both of your reviews.

While we do not see additional value in including the identities in the 
password derivation (given that they are later bound into the shared 
secret), we don't have any problem with it either.

We are fine with making the key derivation function more standard. We 
propose the following change to 
We define a KDF which is modeled on RFC 5869, and in fact becomes HKDF 
when the MAC is an HMAC (note that the draft does *not* constrain MAC 
functions to be an HMAC construction):

      PRF := mac("\0"+, P)
      KEY := mac+(PRF, ID_s | ID_p)
      DHComponent_S := Encr(KEY, y_s)

PRF is truncated or zero-padded if necessary when used to derive KEY. 
Neither is needed when using an HMAC function for the MAC.

The protocol peers should store the MAC'ed password, instead of a 
plaintext password. The peers have a choice of storing the output of the 
first application of MAC, or that of the second application (i.e. salted 
by the identities). The security benefits of the latter should be 
weighed against the operational difficulty associated with changing 
either of the identities.

BTW, we have changed the "kmac" terminology into "mac", per your comments.

The operator mac+ will be redefined as:

mac+(key, string) = T1 | T2 ...

where each Ti is an application of the keyed MAC with a fixed key:

T1 = mac(key, string | 0x01)
T2 = mac(key, T1 | string | 0x02)
T3 = mac(key, T2 | string | 0x03)

Please let us know if this change resolves your concerns.


On 08/17/2010 06:52 AM, Brian Weis wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security
> area directors. Document editors and WG chairs should treat these
> comments just like any other review comments.
> I previously reviewed -06 of this I-D and made a number of suggestions.
> The current version has addressed those as well as other last call
> comments. I have just one concern and one comment regarding the changes
> regarding encrypting DHComponent_S and DHComponent_P in on-the-wire
> payloads. This is described in Sections 5.1, 5.2, and 6.1. I'm going to
> discuss DHComponent_S, but DHComponent_P is similarly changed.
> 1. In -06, DHComponent_S was protected with an IKEv2-style prf+():
> DHComponent_S = Encr(prf+(password, "EAP-EKE Password"), y_s),
> In -07, DHComponent_S is now protected with a "keyed MAC":
> DHComponent_S = Encr(kmac+(password), y_s)
> where kmac+() is defined as:
> kmac+(P) = T1 | T2 | ...
> where each Ti is an application of the keyed MAC with a fixed key:
> T1 = kmac("S"+, P | 0x01)
> T2 = kmac("S"+, T1 | P | 0x02)
> T3 = kmac("S"+, T2 | P | 0x03)
> Dan Harkins suggested an "extractor and expander" KDF, which I believe
> motivated this change. I think the use of a constant "salt" value used
> as a key in kmac+ approximates only the "extractor" function described
> in RFC 5869, and the output of an "extractor" is not intended to be the
> final KDF output. An "expander" function is necessary to follow the
> "extractor" function, and prf+ fits that description. So unless I'm
> mistaken, these section should define two calls: one to kmac() to to
> create an intermediate value of the appropriate size, and the another
> that uses the intermediate value as the key to a prf+ call.
> I think it might be convenient to require the kmac+ and prf+ algorithms
> be the same.
> 2. As far as I can tell, the definition of "kmac" is new to this I-D,
> which I found a bit confusing. It's really just a MAC, so I think it
> would be clearer to just call it a mac().
> Brian
> _______________________________________________
> secdir mailing list