Re: [jose] Concat KDF

"Manger, James H" <James.H.Manger@team.telstra.com> Sat, 13 July 2013 12:34 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 B435F21F9D54 for <jose@ietfa.amsl.com>; Sat, 13 Jul 2013 05:34:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.84
X-Spam-Level:
X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, 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 qZOFfctUo+oj for <jose@ietfa.amsl.com>; Sat, 13 Jul 2013 05:34:50 -0700 (PDT)
Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id E479721F9C51 for <jose@ietf.org>; Sat, 13 Jul 2013 05:34:48 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.89,659,1367935200"; d="scan'208,217"; a="146261556"
Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipobvi.tcif.telstra.com.au with ESMTP; 13 Jul 2013 22:34:44 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,7134"; a="143559438"
Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipccvi.tcif.telstra.com.au with ESMTP; 13 Jul 2013 22:34:44 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Sat, 13 Jul 2013 22:34:43 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: "'jose@ietf.org'" <jose@ietf.org>
Date: Sat, 13 Jul 2013 22:34:40 +1000
Thread-Topic: [jose] Concat KDF
Thread-Index: Ac5/FMun7GSIHl9fSaGTM1tDyctMPwAqAddQ
Message-ID: <255B9BB34FB7D647A506DC292726F6E1151C58C9F4@WSMSG3153V.srv.dir.telstra.com>
References: <4E1F6AAD24975D4BA5B16804296739436B6B953F@TK5EX14MBXC283.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436B6B953F@TK5EX14MBXC283.redmond.corp.microsoft.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_255B9BB34FB7D647A506DC292726F6E1151C58C9F4WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: Re: [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: Sat, 13 Jul 2013 12:34:56 -0000

Concat KDF in draft-ietf-jose-json-web-algorithms-12 can now conform to how NIST SP 800-56A defines it. Yay!

The (last?) issue with Concat KDF is whether or not the recipient needs to verify that PartyVInfo is actually about them.

As currently specified, the recipient of a JOSE message can (and will) mechanically copy the “apu” and “apv” values into the Concat KDF calculation. The recipient will not bother looking “inside” these values, because the spec doesn’t require it. In contrast, the recipient will look “inside” the AlgorithmID value as it is used to select the encryption algorithm. I suspect Concat KDF only achieves the security it is designed to deliver when the recipient does verify PartyVInfo so I doubt Concat KDF is secure as specified.

--
James Manger