Subject: [jose] #161 Password Considerations - Proposed Text

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 7 Nov 2013 16:47:23 +0000

Jim and Mike asked me to take a pass at revising the text in 7.8. Password Considerations.  Here is my proposed changes:

OLD TEXT:

""""

While convenient for end users, passwords are vulnerable to a number of attacks.  To help mitigate some of these limitations, this document applies principles from [RFC2898] to derive cryptographic keys from user-supplied passwords.

However, the strength of the password still has a significant impact. A high-entry password has greater resistance to dictionary attacks. [NIST-800-63-1] contains guidelines for estimating password entropy, which can help applications and users generate stronger passwords.

An ideal password is one that is as large (or larger) than the derived key length but less than the PRF's block size.  Passwords larger than the PRF's block size are first hashed, which reduces an attacker's effective search space to the length of the hash algorithm (32 octets for HMAC SHA-256).  It is RECOMMENDED that the password be no longer than 64 octets long for "PBES2-HS512+A256KW".

Still, care needs to be taken in where and how password-based encryption is used.  Such algorithms MUST NOT be used where the attacker can make an indefinite number of attempts to circumvent the protection.

""""

NEW TEXT:
""""

While convenient for end users, passwords are vulnerable to a number of attacks.  To help mitigate some of these limitations, this document applies principles from [RFC2898] to derive cryptographic keys from user-supplied passwords.

However, the strength of the password still has a significant impact. A high-entry password has greater resistance to dictionary attacks. [NIST-800-63-1] contains guidelines for estimating password entropy, which can help applications and users generate stronger passwords.

An ideal password is one that is as large (or larger) than the derived key length.  However, passwords larger than a certain algorithm-specific size are first hashed, which reduces an attacker's effective search space to the length of the hash algorithm.  It is RECOMMENDED that a password used for "PBES2-HS256+A128KW" be no shorter than 16 octets and no longer than 1289 octets; a password used for "PBES2-HS512+A256KW" be no shorter 32 octets and no longer than 128 octets long.

Still, care needs to be taken in where and how password-based encryption is used.  These algorithms can still be susceptible to dictionary-based attacks if the iteration count is too small; this is of particular concern if these algorithms are used to protect data that an attacker can have indefinite number of attempts to circumvent the protection, such as protected data stored on a file system.

""""

- m&m

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

---

From: Tim Bray <[email-masked]>
Date: Thu, 7 Nov 2013 08:58:04 -0800

I recommend removing the assertion that passwords are convenient for end
users, which is demonstrably false in the 2013 context.

On Thu, Nov 7, 2013 at 8:47 AM, Matt Miller (mamille2)
<[email-masked]>wrote:

> Jim and Mike asked me to take a pass at revising the text in 7.8. Password
> Considerations.  Here is my proposed changes:
>
>
> OLD TEXT:
>
> """"
>
> While convenient for end users, passwords are vulnerable to a number of
> attacks.  To help mitigate some of these limitations, this document applies
> principles from [RFC2898] to derive cryptographic keys from user-supplied
> passwords.
>
> However, the strength of the password still has a significant impact. A
> high-entry password has greater resistance to dictionary attacks.
> [NIST-800-63-1] contains guidelines for estimating password entropy, which
> can help applications and users generate stronger passwords.
>
> An ideal password is one that is as large (or larger) than the derived key
> length but less than the PRF's block size.  Passwords larger than the PRF's
> block size are first hashed, which reduces an attacker's effective search
> space to the length of the hash algorithm (32 octets for HMAC SHA-256).  It
> is RECOMMENDED that the password be no longer than 64 octets long for
> "PBES2-HS512+A256KW".
>
> Still, care needs to be taken in where and how password-based encryption
> is used.  Such algorithms MUST NOT be used where the attacker can make an
> indefinite number of attempts to circumvent the protection.
>
> """"
>
> NEW TEXT:
> """"
>
> While convenient for end users, passwords are vulnerable to a number of
> attacks.  To help mitigate some of these limitations, this document applies
> principles from [RFC2898] to derive cryptographic keys from user-supplied
> passwords.
>
> However, the strength of the password still has a significant impact. A
> high-entry password has greater resistance to dictionary attacks.
> [NIST-800-63-1] contains guidelines for estimating password entropy, which
> can help applications and users generate stronger passwords.
>
> An ideal password is one that is as large (or larger) than the derived key
> length.  However, passwords larger than a certain algorithm-specific size
> are first hashed, which reduces an attacker's effective search space to the
> length of the hash algorithm.  It is RECOMMENDED that a password used for
> "PBES2-HS256+A128KW" be no shorter than 16 octets and no longer than 1289
> octets; a password used for "PBES2-HS512+A256KW" be no shorter 32 octets
> and no longer than 128 octets long.
>
> Still, care needs to be taken in where and how password-based encryption
> is used.  These algorithms can still be susceptible to dictionary-based
> attacks if the iteration count is too small; this is of particular concern
> if these algorithms are used to protect data that an attacker can have
> indefinite number of attempts to circumvent the protection, such as
> protected data stored on a file system.
>
> """"
>
>
> - m&m
>
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 7 Nov 2013 17:08:06 +0000

+1

From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Thursday, November 7, 2013 8:58 AM
To: Matt Miller (mamille2)
Cc: <[email-masked]>
Subject: Re: [jose] #161 Password Considerations - Proposed Text

I recommend removing the assertion that passwords are convenient for end users, which is demonstrably false in the 2013 context.

On Thu, Nov 7, 2013 at 8:47 AM, Matt Miller (mamille2) <[email-masked]<mailto:[email-masked]>> wrote:
Jim and Mike asked me to take a pass at revising the text in 7.8. Password Considerations.  Here is my proposed changes:

OLD TEXT:

""""

""""

NEW TEXT:
""""

""""

- 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: Mike Jones <[email-masked]>
Date: Thu, 7 Nov 2013 19:04:35 +0000

Matt – I assume that the “1289” was a typo and should be “128”?

Also, why was the maximum recommended length for PBES2-HS512+A256KW changed from 64 to 128 octets?  (I’m ok with the change, but did want to understand the rationale for it.)

                                                            Thanks,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Anthony Nadalin
Sent: Thursday, November 07, 2013 9:08 AM
To: Tim Bray; Matt Miller (mamille2)
Cc: <[email-masked]>
Subject: Re: [jose] #161 Password Considerations - Proposed Text

+1

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Tim Bray
Sent: Thursday, November 7, 2013 8:58 AM
To: Matt Miller (mamille2)
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [jose] #161 Password Considerations - Proposed Text

OLD TEXT:

""""

""""

NEW TEXT:
""""

""""

- m&m

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 7 Nov 2013 19:26:10 +0000

> Also, why was the maximum recommended length for PBES2-HS512+A256KW changed from 64 to 128 octets?  (I’m ok with the change, but did want to understand the rationale for it.)

The new recommended maximums are based on the "natural order" of the algorithms in use.  Using 64 octets was rather arbitrary with the algorithms in use, whereas 128 octets meets with the limits of the underlying PRF family (SHA2).

I do understand that 64 octets might be more than anyone wants to type, at least in Latin-influenced dialects.  When you start getting into multi-byte characters like Simplified Chinese, both limits can turn out to be rather small.

- m&m

> On Thu, Nov 7, 2013 at 8:47 AM, Matt Miller (mamille2) <[email-masked]> wrote:

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 8 Nov 2013 10:58:29 +1100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Matt Miller (mamille2)
> 
> NEW TEXT:
> """"
> 
> attacks.  To help mitigate some of these limitations, this document
> applies principles from [RFC2898] to derive cryptographic keys from
> user-supplied passwords.
> 

s/high-entry/high-entropy/

> [NIST-800-63-1] contains guidelines for estimating password entropy,
> which can help applications and users generate stronger passwords.
> 
> An ideal password is one that is as large (or larger) than the derived

s/as large (or larger) than/as large as (or larger than)/

A password as large as the key length is really a key not a password.

> key length.  However, passwords larger than a certain algorithm-
> specific size are first hashed, which reduces an attacker's effective
> search space to the length of the hash algorithm.  It is RECOMMENDED
> that a password used for "PBES2-HS256+A128KW" be no shorter than 16
> octets and no longer than 1289 octets; a password used for "PBES2-

Yuck.
Why 16 octets? Are we trying to recommend 128-bits of entropy and assuming 16 octets provides this because we assume they are random?

If we recommend crypto-strength passwords we may as well recommend using keys directly instead of PBE.

Passwords are characters, not octets.
JWA section 4.9. "Key encryption with PBES2" needs to explicitly state that a password is UTF-8 encoded to get the byte string used by the PBES2 algorithm.

> HS512+A256KW" be no shorter 32 octets and no longer than 128 octets
> long.
> 
> Still, care needs to be taken in where and how password-based
> encryption is used.  These algorithms can still be susceptible to
> dictionary-based attacks if the iteration count is too small; this is

They are susceptible to dictionary attack regardless of iteration count.

> of particular concern if these algorithms are used to protect data that
> an attacker can have indefinite number of attempts to circumvent the
> protection, such as protected data stored on a file system.

This will always apply to JOSE messages. The point of JWE PBE is to keep some content confidential even when an attacker see the JWE message. An indefinite number of attempts can be tried once the attacker has the message, whether from storage or from a transmission.

PBE algs have 2 purposes:
1. To allow a string to be used as a secret, instead of having to use a binary key of a specific length.
2. To add a work factor making dictionary attacks slower when the only secret you have is a low-entropy human-memorable password.

When apps use PBE for the 1st purpose (ie when the password is cryptographically strong, eg >= 128-bits of entropy) the iteration count should be 1, and I don’t think the salt adds anything.

When apps use PBE for the 2nd purpose the password cannot be expected to have high-entropy. Just warn that the encryption is no stronger than the password. I doubt it is worth mentioning upper limits on entropy; nor to try to recommend any password rules (eg at least 16 octets).
Instead of recommending the iteration count be at least 1000 [section 4.9.1.2.], we should recommend that the count be chosen so that the derivation takes a given amount of time, say 1 second.

--
James Manger

---

From: Mike Jones <[email-masked]>
Date: Fri, 8 Nov 2013 00:04:03 +0000

Disagree.  The password input for these algorithms *is* an octet sequence.  However, to avoid confusion, we could say that passwords that are represented as Unicode text strings should use the UTF-8 encoding of the string as the password input to these algorithms.  Does anyone want to propose specific text in that regard?

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, November 07, 2013 3:58 PM
To: Matt Miller (mamille2); <[email-masked]>
Subject: Re: [jose] #161 Password Considerations - Proposed Text

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Matt Miller (mamille2)
> 
> NEW TEXT:
> """"
> 
> While convenient for end users, passwords are vulnerable to a number 
> of attacks.  To help mitigate some of these limitations, this document 
> However, the strength of the password still has a significant impact. 
> A high-entry password has greater resistance to dictionary attacks.

Yuck.

> of particular concern if these algorithms are used to protect data 
> that an attacker can have indefinite number of attempts to circumvent 
> the protection, such as protected data stored on a file system.

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 8 Nov 2013 11:23:13 +1100

>> JWA section 4.9. "Key encryption with PBES2" needs to explicitly state
>> that a password is UTF-8 encoded to get the byte string used by the
>> PBES2 algorithm.

> Disagree.  The password input for these algorithms *is* an octet
> sequence.  However, to avoid confusion, we could say that passwords
> that are represented as Unicode text strings should use the UTF-8
> encoding of the string as the password input to these algorithms.  Does
> anyone want to propose specific text in that regard?

Lets not repeat the interop hassles with BASIC and DIGEST that didn’t specify a char-to-octet mapping for passwords.

JWA doesn't say "the password *is* an octet sequence". It says it derives a key from "a user-supplied password". Users type in chars, not bytes. Even text config files supply chars, not bytes.

Suggested text for the end of the 1st paragraph of JWA section 4.9:

  The user-supplied password MUST be UTF-8 encoded to give the
  octet string password used by the PBES2 schemes.

--
James Manger

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 8 Nov 2013 00:50:04 +0000

>  octet string password used by the PBES2 schemes.

James is right.  Only ASCII provides anything close to a perfect mapping of character-to-octet.  The password considerations does need to say the above, but it also needs to say something about normalization, or lack thereof.  We need some input from some real PRECIS people on this.  My original draft had some internationalization considerations in it that might be a good starting point.

- m&m

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Fri, 8 Nov 2013 00:58:15 +0000

> James is right.  Only ASCII provides anything close to a perfect mapping of character-to-octet.  The password considerations does need to say the above, but it also needs to say something about nor…

And that original text is:

""""

   Passwords obtained from users are likely to require preparation and
   normalization to account for differences of octet sequences generated
   by different input devices, locales, etc.  It is RECOMMENDED for
   applications to perform the steps outlined in [SASLPREP] to prepare a
   password supplied directly by a user before performing key derivation
   and encryption.

""""

- m&m

---

From: Mike Jones <[email-masked]>
Date: Sat, 9 Nov 2013 00:33:12 +0000

I believe that the following text addresses the encoding issue that James raised:

	  The PBES2 password input is an octet sequence;
	  if the password to be used is represented as a text string
	  rather than an octet sequence, the UTF-8 encoding of the text string
	  SHOULD be used as the octet sequence.

If you'd like to see any changes made to it, please propose specific edits.

(The SASLPREP text is already present in the Internationalization Considerations section.)

				Thanks,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Thursday, November 07, 2013 3:58 PM
To: Matt Miller (mamille2); <[email-masked]>
Subject: Re: [jose] #161 Password Considerations - Proposed Text

Yuck.

--
James Manger

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 11 Nov 2013 11:36:21 +1100

> ----------
> From: Mike Jones [mailto:[email-masked]]
> 

At least change SHOULD to MUST.

--
James Manger

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 10 Nov 2013 18:47:36 -0800

> Manger, James H
> Sent: Sunday, November 10, 2013 4:36 PM
> To: Mike Jones; Matt Miller (mamille2); <[email-masked]>

If it is not changed then there needs to be a lot of description about why
this is not a MUST.  If this is the case then it would be logical that two
different implementations could do different decisions and never
interoperate.

I would say that we should make a normative reference to the
draft-melnikov-precis-saslprepbis as well.  If not then we will probably get
hit by the ADs.

Jim

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 Nov 2013 05:00:58 +0000

I'm OK with the MUST.  But can anyone give us a status update on draft-ietf-precis-saslprepbis?  It doesn't appear to be in the RFC Editor queue.  I'm worried that if we make a normative reference, JWA will be held up in the RFC editor queue for on reference, just like draft-ietf-appsawg-acct-uri is currently held up in the RFC Editor queue on a reference to draft-ietf-precis-framework, which has not yet been received by the RFC Editor.

				-- Mike

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: Sunday, November 10, 2013 6:48 PM
To: 'Manger, James H'; Mike Jones; 'Matt Miller (mamille2)'; [email-masked]
Subject: RE: [jose] #161 Password Considerations - Proposed Text

> Of Manger, James H

If it is not changed then there needs to be a lot of description about why this is not a MUST.  If this is the case then it would be logical that two different implementations could do different decisions and never interoperate.

I would say that we should make a normative reference to the draft-melnikov-precis-saslprepbis as well.  If not then we will probably get hit by the ADs.

Jim

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 11 Nov 2013 16:21:03 +0000

The document draft-ietf-precis-saslprepbis competed a WG LC a few weeks ago, but went through a fair amount of changes recently.  A discussion with some Kitten WG folk is pending to make sure their concerns are addressed.  It might go through another WG LC.  The foundational documents for PRECIS (draft-ietf-precis-framework and draft-ietf-precis-mappings) completed WG LC; the consensus was that precis-framework is ready for IETF LC, but precis-mapping might not be (each has a normative reference to the other, and saslprepbis has a normative reference to precis-framework).

- m&m

---

From: Mike Jones <[email-masked]>
Date: Mon, 11 Nov 2013 16:33:52 +0000

So it sounds like these won't complete anytime soon, in other words. :-/

-----Original Message-----
From: Matt Miller (mamille2) [mailto:[email-masked]] 
Sent: Monday, November 11, 2013 8:21 AM
To: Mike Jones
Cc: Jim Schaad; Manger, James H; [email-masked]
Subject: Re: [jose] #161 Password Considerations - Proposed Text

- m&m