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

The registry is there exactly to prevent such messes.  They have a good track record of preventing them to date. ;-)

                                                                -- Mike

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

“s” and “c” at the top level (not under “jwk”) would at least be more consistent with other parts of JOSE and the design philosophy of “keep it flat”. I would actually prefer sticking “s” and “c” into a sub-object, but it only makes sense if other fields are moved there as well. What if a key wrapping algorithm and a content encryption algorithm both need a salt? What if a sender key and recipient key have the same sort of parameter (such as a “kid”)? The “simplicity” of a flat structure quickly becomes a mess.

--
James Manger

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, 17 July 2013 9:17 AM
To: Matt Miller (mamille2)
Cc: Manger, James H; jose@ietf.org<mailto: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