[jose] NIST Concat KDF

"Manger, James H" <James.H.Manger@team.telstra.com> Tue, 30 October 2012 13:13 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0080721F84B5 for <jose@ietfa.amsl.com>; Tue, 30 Oct 2012 06:13:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.959
X-Spam-Level:
X-Spam-Status: No, score=0.959 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo-DGLgYDXTd for <jose@ietfa.amsl.com>; Tue, 30 Oct 2012 06:13:22 -0700 (PDT)
Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id EB07021F84D6 for <jose@ietf.org>; Tue, 30 Oct 2012 06:13:21 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.80,680,1344175200"; d="scan'208,217"; a="100516302"
Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 31 Oct 2012 00:13:19 +1100
X-IronPort-AV: E=McAfee;i="5400,1158,6880"; a="95337613"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcdvi.tcif.telstra.com.au with ESMTP; 31 Oct 2012 00:13:16 +1100
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 31 Oct 2012 00:13:18 +1100
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "jose@ietf.org" <jose@ietf.org>
Date: Wed, 31 Oct 2012 00:13:16 +1100
Thread-Topic: NIST Concat KDF
Thread-Index: Ac22LuWgSDJoAVpDQL23HP4i5KxmTwACPfUA
Message-ID: <255B9BB34FB7D647A506DC292726F6E114FFB9FC5D@WSMSG3153V.srv.dir.telstra.com>
References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <CE8995AB5D178F44A2154F5C9A97CAF40252198DCF55@HE111541.emea1.cds.t-internal.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> <CE8995AB5D178F44A2154F5C9A97CAF40252199B9114@HE111541.emea1.cds.t-internal.com> <BF7E36B9C495A6468E8EC573603ED94115076832@xmb-aln-x11.cisco.com> <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> <CAHcDwFwAD-EJBytkYE0q0GPZduKJUnvO8s69wTbZjZt2Cgo+Lg@mail.gmail.com>
In-Reply-To: <CAHcDwFwAD-EJBytkYE0q0GPZduKJUnvO8s69wTbZjZt2Cgo+Lg@mail.gmail.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E114FFB9FC5DWSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: [jose] NIST Concat KDF
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Oct 2012 13:13:29 -0000

JOSE still doesn’t use the NIST 800-56A Concat Key DF as that specification requires.

JWA allows PartyUInfo and/or PartyVInfo to be empty (if apu/apv/epu/epv are absent). That doesn’t comply with 800-56A that says “at a minimum, PartyUInfo shall include IDu, the identity of party U”. 800-56A also says “it is required that identifier for both parties to a key agreement transaction be included in the OtherInfo that is input to the key derivation function”.

800-56A requires that the concatenation AlgorithmID || PartyUInfo || PartyVInfo be unambiguous. It allows two ways to achieve this: pre-define fixed sizes for components; or prefix each component with its length. JWA does neither of these.

Consider two JOSE messages (ignoring some irrelevant base64url encoding):
  { ..., "apu":"JoBeth", "apv":"Anne" } and
  { ..., "apu":"Jo", "apv":"BethAnne" }
JWA implies both use the string "JoBethAnne" in the KDF despite the messages being between different parties, which defeats this part of the Concat KDF design.

JWA explicitly puts the key length and "alg" value into the AlgorithmID field that the KDF uses. However, the "alg" value alone must imply one specific key length for the rest of the JOSE processing to work so including the key length explicitly is redundant.

800-56A is designed to derive integrity and encryption keys together. For instance, it says “AlgorithmID might indicate that bits 1-80 are to be used as an 80-bit HMAC key and that bits 81-208 are to be used as a 128-bit AES key”. JWA does not do this. JWA runs the KDF twice to derive integrity and encryption keys separately.

If we want to use NIST 800-56A Concat KDF then JWA/JWE needs lots of fixes.
If we want a simpler KDF then JWA shouldn’t pretend it is the NIST 800-56A Concat KDF.

--
James Manger