Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-08

[Nico Williams <[e-mail]>]

On Fri, Jan 15, 2016 at 12:25:58PM -0500, Greg Hudson wrote:
> I did another read-through of the draft.  I found some minor issues,
> which I hope can be resolved without requiring another WGLC.

I did as well.  I don't have anything substantial to add to your
comments:

> * Section 8 says, "The salt and iteration count resist brute force and
> dictionary attacks, however, it is still important to choose or generate
> strong passphrases."  This is a run-on sentence; the comma preceding
> "however" should be a semicolon.

   The use PBKDF2, a salt, and a large iteration count, adds some
   resistance to off-line dictionary attacks by passive eavesdroppers.
   Salting prevents rainbow table attacks, while large iteration counts
   slow password guess attempts.  Nonetheless, it is important to choose
   strong passphrases, and/or to use other Kerberos extensions that
   protect against off-line dictionary attacks.  For example, FAST
   [RFC6113] with a suitable armor ticket, or a future password-
   authenticated key exchange (PAKE) pre-authentication method.

> * Section 8.1 says, "ktutil's add_entry command assumes the default
> salt."  That might be too specific; I suggest "Some key table
> manipulation programs assume the default salt when adding entries based
> on passwords."

Even the words "key table" are a bit too specific.  The salient point is
that non-interaction with the KDC implies not knowing the salt;
utilities that need a salt but do not or cannot interact with a KDC to
find out what the salt is need a default salt, and that needs to work
else such utilities cannot.

ktutil in particular could have an option to learn the salt, but if it
has to work off-line then it cannot.

Lastly, as to not every random salt being a UTF-8 string, it is possible
to increase the length of the salt to accomodate any NIST guidance as to
entropy content of salts when they are generated.

Nico
--