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

Brian Weis <bew@cisco.com> Fri, 10 September 2010 18:16 UTC

Return-Path: <bew@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06FB3A685C for <secdir@core3.amsl.com>; Fri, 10 Sep 2010 11:16:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Level:
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lwl8GICpgeuA for <secdir@core3.amsl.com>; Fri, 10 Sep 2010 11:16:46 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F365B3A6819 for <secdir@ietf.org>; Fri, 10 Sep 2010 11:16:45 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAL4SikyrR7Hu/2dsb2JhbAChQ3GkB5sugwgGgi8EhEVShQmCfA
X-IronPort-AV: E=Sophos;i="4.56,347,1280707200"; d="scan'208";a="253271130"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 10 Sep 2010 18:17:12 +0000
Received: from [128.107.147.206] ([128.107.147.206]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o8AIHCYP016825; Fri, 10 Sep 2010 18:17:12 GMT
Message-Id: <C40F4DAA-D503-4554-980C-A7FA3B8A109D@cisco.com>
From: Brian Weis <bew@cisco.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
In-Reply-To: <4C85295D.5010209@gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 10 Sep 2010 11:17:09 -0700
References: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com> <4C85295D.5010209@gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: Tim Polk <tim.polk@nist.gov>, draft-sheffer-emu-eap-eke@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Sep 2010 18:16:48 -0000

Hi Yaron,

That approach below looks good to me.

Regarding including the identities in the salt: I do note that the  
HKDF paper referenced by RFC 5869 states several times that the salt  
should be either a constant value (e.g., "\0"), or a value chosen at  
random, which I presume means that different values will be uniformly  
distributed over the size of the salt. I don't see a clear explanation  
in the paper why this is so (other than a hint in Section 9 that a  
random salt "prevents building universal dictionaries"). Since the  
identities aren't going to be random so it may be better to simply use  
the static value.

Thanks,
Brian

On Sep 6, 2010, at 10:48 AM, Yaron Sheffer wrote:

> 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 http://tools.ietf.org/id/draft-sheffer-emu-eap-eke-08.html#commit-request 
> . 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.
>
> Thanks,
> 	Yaron
>
> 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
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir


-- 
Brian Weis
Security Standards and Technology, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@cisco.com