[jose] Concat KDF

"Manger, James H" <James.H.Manger@team.telstra.com> Mon, 17 June 2013 01:20 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 DF01921F9B66 for <jose@ietfa.amsl.com>; Sun, 16 Jun 2013 18:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level:
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRWIpR24Ej63 for <jose@ietfa.amsl.com>; Sun, 16 Jun 2013 18:20:35 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7449421F9B63 for <jose@ietf.org>; Sun, 16 Jun 2013 18:20:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.87,877,1363093200"; d="scan'208";a="142865964"
Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 17 Jun 2013 11:20:26 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7108"; a="145157199"
Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipccni.tcif.telstra.com.au with ESMTP; 17 Jun 2013 11:20:26 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Mon, 17 Jun 2013 11:20:26 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "jose@ietf.org" <jose@ietf.org>
Date: Mon, 17 Jun 2013 11:20:25 +1000
Thread-Topic: Concat KDF
Thread-Index: Ac5q+NhbtqGMiV/SQhaOAzsJ13w6TQ==
Message-ID: <255B9BB34FB7D647A506DC292726F6E1151B930A31@WSMSG3153V.srv.dir.telstra.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: [jose] 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: Mon, 17 Jun 2013 01:20:42 -0000

The use of the Concat KDF still does not look right.

JWA [draft-ietf-jose-json-web-algorithms-11] section 4.7 says "ECDH-ES" uses Concat KDF from NIST 800-56A section 5.8.1. NIST defines 5 fields that go into the key derivation: AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo, and SuppPrivInfo.

NIST says AlgorithmID indicates the algorithm that will use the derived key. JWA says to use the "alg" value (eg "ECDH-ES") as the AlgorithmID. AlgorithmID should actually be the "enc" value when the derived key is used directly as a CEK. When the derived key unwraps the CEK, AlgorithmID should be the name of the key wrap algorithm (eg "A128KW"). Perhaps the "alg" value can be used in this case as it identifies the key wrap algorithm along with the key establishment algorithm (eg "ECDH-ES+A128KW").

NIST says PartyUInfo includes an identifier for party U. The first problem is that JWA does not indicate if the sender or receiver is party U (nor does JWE). The second problem is that JWA says PartyUInfo is random -- which seems to totally defeat the purpose of being an identifier for a party. JWA says PartyUInfo should vary for each recipient, which suggests PartyUInfo cannot be an id of the sender. Does that suggest the receiver is party U?

NIST says PartyVInfo is required and includes an identifier for party V. JWA says PartyVInfo is empty, which obviously cannot meet the NIST definition.

The JWA values for SuppPubInfo (length of derived key in bits) and SuppPrivInfo (empty) are in line with the NIST definitions.


It appears the Concat KDF text in JWA has been rewritten based on RFC2631 "Diffie-Hellman Key Agreement Method". RFC2631 is not referenced by JWA, but it is mentioned in the "document history" section (which will eventually be deleted). RFC2631 has items such as partyAInfo and suppPubInfo whose names are similar to NIST items. However, RFC2631 was published 7 years before NIST 800-56A (and 13 years before the current version of NIST 800-56A) so RFC2631 cannot be used as a example of how to use Concat KDF.

--
James Manger