Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

Mike Jones <Michael.Jones@microsoft.com> Tue, 16 July 2013 23:45 UTC

Return-Path: <Michael.Jones@microsoft.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 281E121F9D66 for <jose@ietfa.amsl.com>; Tue, 16 Jul 2013 16:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.715
X-Spam-Level:
X-Spam-Status: No, score=-3.715 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 SvqXg1506S8W for <jose@ietfa.amsl.com>; Tue, 16 Jul 2013 16:45:49 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4D321F9DDE for <jose@ietf.org>; Tue, 16 Jul 2013 16:45:47 -0700 (PDT)
Received: from BY2FFO11FD018.protection.gbl (10.1.15.201) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.0.717.3; Tue, 16 Jul 2013 23:30:41 +0000
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD018.mail.protection.outlook.com (10.1.14.106) with Microsoft SMTP Server (TLS) id 15.0.717.3 via Frontend Transport; Tue, 16 Jul 2013 23:30:41 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.146]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0136.001; Tue, 16 Jul 2013 23:30:36 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Richard Barnes <rlb@ipv.sx>, "Matt Miller (mamille2)" <mamille2@cisco.com>
Thread-Topic: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?
Thread-Index: Ac6Bwa7E5l6r/DDHRwe+2UU0iYcgFQA1v0SA///D1wD///0PMA==
Date: Tue, 16 Jul 2013 23:30:35 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436B6C8153@TK5EX14MBXC283.redmond.corp.microsoft.com>
References: <255B9BB34FB7D647A506DC292726F6E1151C7C31BF@WSMSG3153V.srv.dir.telstra.com> <BF7E36B9C495A6468E8EC573603ED941152C0944@xmb-aln-x11.cisco.com> <CAL02cgQF1O67LMivM+tzuAb-6BawPDL1m0mPC7+s=FzN7zrjwg@mail.gmail.com>
In-Reply-To: <CAL02cgQF1O67LMivM+tzuAb-6BawPDL1m0mPC7+s=FzN7zrjwg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.79]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436B6C8153TK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704005)(199002)(189002)(24454002)(377454003)(81542001)(15202345003)(74876001)(56776001)(44976005)(551544002)(76482001)(4396001)(74706001)(6806004)(80022001)(66066001)(512954002)(53806001)(74662001)(81342001)(46102001)(63696002)(54316002)(47736001)(50986001)(20776003)(55846006)(79102001)(71186001)(77096001)(74366001)(56816003)(49866001)(47976001)(76786001)(16406001)(77982001)(59766001)(83072001)(16236675002)(65816001)(69226001)(19300405004)(51856001)(74502001)(33656001)(76796001)(47446002)(54356001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB037; H:TK5EX14HUBC103.redmond.corp.microsoft.com; CLIP:131.107.125.37; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 09090B6B69
Cc: "Manger, James H" <James.H.Manger@team.telstra.com>, "jose@ietf.org" <jose@ietf.org>
Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?
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, 16 Jul 2013 23:45:55 -0000

If we move "s" and "c" to being header parameters from the JWK, would we still need the JWK with "kty":"PBKDF2"?  All that would be left would be the "hint" JWK parameter.

                                                                -- Mike

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, July 16, 2013 4:17 PM
To: Matt Miller (mamille2)
Cc: Manger, James H; jose@ietf.org
Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

Like James, I don't think -13 (or draft-miller-jose-jwe-protected-jwk) is quite right in how the parameters are laid out.  PBES should be exactly like ECDH -- the parameters for the KEK derivation and key encryption all go in the header.  The JWE header for an ECDH-protected JWE might look like this:

{
  "alg":"ECDH-ES+A128KW",
  "kid":"27a4c46f-6d36-4a8c-814c-c954165f6dc9",
  "epk":{...},
  "apu":"...",
  "apv":"...",
  "enc":"A128CBC+HS256",
  "cty":"application/jwk+json"
}

So the example JWE header in draft-miller-jose-jwe-protected-jwk would be:

{
  "alg":"PBES2-HS256+A128KW",
  "kid":"27a4c46f-6d36-4a8c-814c-c954165f6dc9",
  "s":"2WCTcJZ1Rvd_CJuJripQ1w",
  "c":4096,
  "enc":"A128CBC+HS256",
  "cty":"application/jwk+json"
}

Similarly, if we were to, say, define an algorithm identifier "PBES2-HS256+A128GCM", the "iv" and "tag" fields would go in the header as well.

{
  "alg":"PBES2-HS256+A128KW",
  "kid":"27a4c46f-6d36-4a8c-814c-c954165f6dc9",
  "s":"2WCTcJZ1Rvd_CJuJripQ1w",
  "c":4096,
  "iv":"lyjGhnbbzu6nEx2MkgTl2Q",
  "tag":"S7mmAbr3AeXVbsTP0M3e4w",
  "enc":"A128CBC+HS256",
  "cty":"application/jwk+json"
}






On Tue, Jul 16, 2013 at 5:52 PM, Matt Miller (mamille2) <mamille2@cisco.com<mailto:mamille2@cisco.com>> wrote:
I would like to first note that the vast majority of the password-based text came from draft-miller-jose-jwe-protected-jwk (discussed a few times on this list), and was included between the end of the JOSE virtual interim (2013-07-15T17:00Z) and the submission deadline.

On Jul 15, 2013, at 7:13 PM, "Manger, James H" <James.H.Manger@team.telstra.com<mailto:James.H.Manger@team.telstra.com>> wrote:

> draft-ietf-jose-json-web-algorithms-13 adds password-based encryption algorithms that involve a salt (s) and iteration count (c). I cannot quite tell how s & c are conveyed. Section 4.9.1 "PBES2-HS256+A128KW" says s & c come from the "applicable PBKDF2 JWK object".
>
> Is the "applicable PBKDF2 JWK object" the value of the "jwk" header parameter in a JWE message?
> Or is the "applicable PBKDF2 JWK object" part of each parties locally-configured key set (which is not part of a message, but can be referenced by a "kid" header parameter)?
The "applicable PBKDF2 JWK object" is whichever of the key-identifying fields ("jwk", "jku", or "kid") works for your application.  The intent of these algorithms is to protect private- or symmetric-key JWK objects, and to be as self-contained as possible, so the original examples used "jwk".  When this was put together, using JWK objects seemed to make the most sense and fit the syntax and semantics.

>
> The latter makes little sense as salt and iteration count are parameters of a particular message, not fixed for a given password.
>
Those are good points, and favor moving "c" and "s" from a JWK into the JWE header (as implicitly proposed elsewhere in this thread).  See above for the original rationale.

> The former is at best underspecified. "jwk" is defined as "the public key to which the JWE was encrypted" [http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-13#section-4.1.5]. s & c obviously are not a public key so that definition would need to change.
>
> A PBKDF2 JWK object is also defined to have a 'hint' parameter ("a descriptive clue to the password"). It would be awful if 'hint's were sent in JOSE messages. JWK needs to do a much better job of separating sensitive fields (secret key, private key, password hint) from public fields. If we need text to display when prompting for a password I think we need a different field to 'hint'.
>
Do you have suggested changes/replacements.

> An example of PBES2-HS256+A128KW would help.
>
I'll let Mike Jones speak to this revision specifically.  An example does exist in the original draft-miller-jose-jwe-protected-jwk.


- m&m

Matt Miller < mamille2@cisco.com<mailto:mamille2@cisco.com> >
Cisco Systems, Inc.


_______________________________________________
jose mailing list
jose@ietf.org<mailto:jose@ietf.org>
https://www.ietf.org/mailman/listinfo/jose