[secdir] Secdir review of draft-sheffer-emu-eap-eke-07
Brian Weis <bew@cisco.com> Tue, 17 August 2010 03:52 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 CDFEE3A6843; Mon, 16 Aug 2010 20:52:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Bn5EQiAHN+Kb; Mon, 16 Aug 2010 20:52:08 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EF4863A6842; Mon, 16 Aug 2010 20:52:07 -0700 (PDT)
Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAD+kaUyrRN+J/2dsb2JhbACgS3GibpwYgxGCKgSELYU1
X-IronPort-AV: E=Sophos;i="4.55,380,1278288000"; d="scan'208";a="574426966"
Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 17 Aug 2010 03:52:43 +0000
Received: from stealth-10-32-244-213.cisco.com (stealth-10-32-244-213.cisco.com [10.32.244.213]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7H3qhKl020142; Tue, 17 Aug 2010 03:52:43 GMT
Message-Id: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com>
From: Brian Weis <bew@cisco.com>
To: secdir@ietf.org, iesg@ietf.org
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 16 Aug 2010 20:52:42 -0700
X-Mailer: Apple Mail (2.936)
Cc: draft-sheffer-emu-eap-eke@tools.ietf.org
Subject: [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: Tue, 17 Aug 2010 03:52:08 -0000
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] Secdir review of draft-sheffer-emu-eap-e… Brian Weis
- Re: [secdir] Secdir review of draft-sheffer-emu-e… Sean Turner
- Re: [secdir] Secdir review of draft-sheffer-emu-e… Yaron Sheffer
- Re: [secdir] Secdir review of draft-sheffer-emu-e… Yaron Sheffer
- Re: [secdir] Secdir review of draft-sheffer-emu-e… Dan Harkins
- Re: [secdir] Secdir review of draft-sheffer-emu-e… Dan Harkins
- Re: [secdir] Secdir review of draft-sheffer-emu-e… Scott Fluhrer (sfluhrer)
- Re: [secdir] Secdir review of draft-sheffer-emu-e… Brian Weis