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

From: "Manger, James H" <[email-masked]>
Date: Tue, 16 Jul 2013 11:13:30 +1000

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 latter makes little sense as salt and iteration count are parameters of a particular message, not fixed for a given password.

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'.

An example of PBES2-HS256+A128KW would help.

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 16 Jul 2013 11:47:51 +1000

A related question is why are "s" and "c" (associated with PBES2-HS256+A128KW) put inside the "jwk" header parameter, while "iv" and "tag" (associated with A128GCMKW) are put as top-level header parameters?

--
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Manger, James H
> Sent: Tuesday, 16 July 2013 11:14 AM
> To: [email-masked]
> Subject: [jose] PBES2-HS256+A128KW: where do salt and iteration count
> go?
> 
> 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".
> 
> 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 latter makes little sense as salt and iteration count are
> parameters of a particular message, not fixed for a given password.
> 
> 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'.
> 
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Tue, 16 Jul 2013 21:52:27 +0000

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.

> 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.

> 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…

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 < [email-masked] >
Cisco Systems, Inc.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Jul 2013 19:17:08 -0400

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)
<[email-masked]>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.
>
> 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".
> >
> > 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
> 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.
>
> 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.
> >
> 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'.
> >
>
> 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
>

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Jul 2013 19:37:21 -0400

I was thinking that the "jwk" would be unnecessary.  We could have "hint"
at the top level, or just use "kid" for that purpose.

--Richard

On Tue, Jul 16, 2013 at 7:30 PM, Mike Jones <[email-masked]>wrote:

>  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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Richard Barnes
> *Sent:* Tuesday, July 16, 2013 4:17 PM
> *To:* Matt Miller (mamille2)
> *Cc:* Manger, James H; [email-masked]
> *Subject:* Re: [jose] PBES2-HS256+A128KW: where do salt and iteration
> count go?****
>
> ** **
>
> this:****
> ** **
> {****
>   "alg":"ECDH-ES+A128KW",****
>
>   "kid":"27a4c46f-6d36-4a8c-814c-c954165f6dc9",****
>
>   "epk":{...},****
>
>   "apu":"...",****
>
>   "apv":"...",****
>
>   "enc":"A128CBC+HS256",****
>
>   "cty":"application/jwk+json"****
>
> }****
>
> ** **
>
> ****
> ** **
> {****
>   "alg":"PBES2-HS256+A128KW",****
>
>   "kid":"27a4c46f-6d36-4a8c-814c-c954165f6dc9",****
>
>   "s":"2WCTcJZ1Rvd_CJuJripQ1w",****
>
>   "c":4096,****
>
>   "enc":"A128CBC+HS256",****
>
>   "cty":"application/jwk+json"****
>
> }****
>
> ** **
>
> 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) <
> [email-masked]> wrote:****
>
> (2013-07-15T17:00Z) and the submission deadline.****
>
>
> referenced by a "kid" header parameter)?****
>
> sense and fit the syntax and semantics.****
>
>
> >
> >****
> for the original rationale.****
>
>
> >****
> Do you have suggested changes/replacements.****
>
>
> >****
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 16 Jul 2013 23:30:35 +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: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, July 16, 2013 4:17 PM
To: Matt Miller (mamille2)
Cc: Manger, James H; [email-masked]
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",

{

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.

{

On Tue, Jul 16, 2013 at 5:52 PM, Matt Miller (mamille2) <[email-masked]<mailto:[email-masked]>> 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.

- m&m

Matt Miller < [email-masked]<mailto:[email-masked]> >
Cisco Systems, Inc.

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 17 Jul 2013 10:08:21 +1000

"kty":"PBKDF2" feels unnecessary, though "kty":"password" would be useful. A key set could have an entry like the following:

{
  "kty":"password",
 "alg":" PBES2-HS256+A128KW",
 "c-min":2000,
 "prompt":"Payment approval PIN",
 "hint":"last 4 digits of \u03C0"
}

The entry could also have a "password" field holding the actual password.
Mind you, I think mixing public (eg kty, alg) and sensitive (eg hint, password) fields side-by-side in a JSON object is a design guaranteed to lead to security breaches from poor handling.

--
James Manger

From: Richard Barnes [mailto:[email-masked]]
Sent: Wednesday, 17 July 2013 9:37 AM
To: Mike Jones
Cc: Matt Miller (mamille2); Manger, James H; [email-masked]
Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

I was thinking that the "jwk" would be unnecessary.  We could have "hint" at the top level, or just use "kid" for that purpose.

--Richard

On Tue, Jul 16, 2013 at 7:30 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
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.

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 17 Jul 2013 10:31:05 +1000

“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

Sent: Wednesday, 17 July 2013 9:17 AM

{
  "alg":"ECDH-ES+A128KW",

{

{

- m&m

---

From: Mike Jones <[email-masked]>
Date: Wed, 17 Jul 2013 00:37:42 +0000

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

                                                                -- Mike

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

--
James Manger

Cc: Manger, James H; [email-masked]<mailto:[email-masked]>

{
  "alg":"ECDH-ES+A128KW",

{

{

- m&m

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 17 Jul 2013 01:51:38 +0000

I think the basic concept is fine, but I would rather not add any more human-facing fields.  It has too much potential to open the Pandora's box that is localization and internationalization.  Hint is something one human enters directly (I assume), so said human could communicate it to other humans.

I do understand your concerns with "password" (or "pwd" to continue our exuberant use of three-letter fields), but that seems like a more general issue to discuss.

- m&m

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 17 Jul 2013 14:17:29 +1000

·          “exp” was changed to “xpo” then to “e” due to potential clashes between very different contexts.

·         “iv” was defined (draft-04) for use with some “enc” values, and now is defined for use with some “alg” values instead.

·         “alg”, “enc”, (and “int” and “mac” and “kdf” in drafts) have been required to identify the context for algorithm ids, but there is no corresponding indication of the context for any parameters associated with those algorithm ids (s, c, iv, tag, apv etc).

·         “kid” sometimes identifies the sender’s key and sometimes the recipient’s key, which isn’t going to be pretty when an alg involves keys from both parties (and there are plenty of such algs).

·         A whole bunch of key-related fields that made sense in JWS (referring to the sender’s key) were switched around in JWE (referring to the recipient’s key) were they are almost pointless but can no longer be used if the sender of a JWE does have a key that needs referencing.

·         The sender’s public key can be held in “jwk”, except in a JWE where a new name is needed: “epk”.

A registry has not prevented the mess. Being drafts has allowed us to create & modify the mess so it can still work. ;-(

We have a strange situation today where a fields such as "kid", "x5t", "x5u", and "x5c" are defined for use in a JWK; there is a field in JWE & JWS to hold a JWK; but JWE & JWS also define top-level use of these fields. Are both of the following ok, equivalent, interoperable?

  { "alg":"xxx", "jwk":{"kid":"123", "x5u":"https://x.y.x/"}}

  { "alg":"xxx", "kid":"123", "x5u":"https://x.y.x/"}

--
James Manger

From: Mike Jones [mailto:[email-masked]]
Sent: Wednesday, 17 July 2013 10:38 AM
To: Manger, James H; Richard Barnes; Matt Miller (mamille2); [email-masked]
Subject: RE: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

                                                                -- Mike

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

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Thu, 18 Jul 2013 18:39:32 +0000

Wearing my editor's hat, it seems like the direction from the working group is to make the salt and iteration count be explicit header parameter values and to drop the "kty":"PBKDF2".  Any disagreement, or shall I do that in the next drafts?

FYI, I was thinking that I'd use "slt" and "itc" for the parameter names.

				-- Mike

-----Original Message-----
From: Matt Miller (mamille2) [mailto:[email-masked]] 
Sent: Tuesday, July 16, 2013 6:52 PM
To: Manger, James H
Cc: Richard Barnes; Mike Jones; [email-masked]
Subject: Re: [jose] PBES2-HS256+A128KW: where do salt and iteration count go?

- m&m

---

From: Richard Barnes <[email-masked]>
Date: Fri, 19 Jul 2013 12:56:16 -0400

If we can spare one more octet, how about "salt" and "iter"?  Otherwise, I
would be fine keeping "s" and "c", or maybe "p2s" and "p2c" to indicate
their use with PBKDF2.

On Thu, Jul 18, 2013 at 2:39 PM, Mike Jones <[email-masked]>wrote:

> Wearing my editor's hat, it seems like the direction from the working
> group is to make the salt and iteration count be explicit header parameter
> values and to drop the "kty":"PBKDF2".  Any disagreement, or shall I do
> that in the next drafts?
>
> I think the basic concept is fine, but I would rather not add any more
> human-facing fields.  It has too much potential to open the Pandora's box
> that is localization and internationalization.  Hint is something one human
> enters directly (I assume), so said human could communicate it to other
> humans.
>
> I do understand your concerns with "password" (or "pwd" to continue our
> exuberant use of three-letter fields), but that seems like a more general
> issue to discuss.
>
>
> - m&m
>
> > "kty":"PBKDF2" feels unnecessary, though "kty":"password" would be
> useful. A key set could have an entry like the following:
> >
> > {
> >  "kty":"password",
> > Mind you, I think mixing public (eg kty, alg) and sensitive (eg hint,
> password) fields side-by-side in a JSON object is a design guaranteed to
> lead to security breaches from poor handling.
> >
> > --
> > James Manger
> >
> > I was thinking that the "jwk" would be unnecessary.  We could have
> "hint" at the top level, or just use "kid" for that purpose.
> >
> > --Richard
> >
> > On Tue, Jul 16, 2013 at 7:30 PM, Mike Jones <[email-masked]
> <mailto:[email-masked]>> wrote:
> > 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.
>
>