[secdir] secdir review of draft-harkins-salted-eap-pwd-06

Simon Josefsson <simon@josefsson.org> Thu, 22 September 2016 07:31 UTC

Return-Path: <simon@josefsson.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 64E8612D903; Thu, 22 Sep 2016 00:31:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PTc-2VmR5ege; Thu, 22 Sep 2016 00:31:33 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 970D912D8FE; Thu, 22 Sep 2016 00:31:32 -0700 (PDT)
Received: from latte.josefsson.org ([]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u8M7VSGk002527 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 22 Sep 2016 09:31:29 +0200
X-Hashcash: 1:22:160922:iesg@ietf.org::8gsWeRiWxqRk2Bv8:hfx
X-Hashcash: 1:22:160922:secdir@ietf.org::J/JP5R1z7GCPsBG/:qlj6
X-Hashcash: 1:22:160922:draft-harkins-salted-eap-pwd.all@ietf.org::N9IQRO2+FCut9MDI:861A
From: Simon Josefsson <simon@josefsson.org>
To: iesg@ietf.org, secdir@ietf.org, draft-harkins-salted-eap-pwd.all@ietf.org
OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt
Date: Thu, 22 Sep 2016 09:31:26 +0200
Message-ID: <87fuosqtkh.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Virus-Scanned: clamav-milter 0.99.2 at duva.sjd.se
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/W8UkcYZcLth457U5hCwLEsSk72U>
Subject: [secdir] secdir review of draft-harkins-salted-eap-pwd-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2016 07:31:35 -0000


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document adds support for salted password databases to EAP-pwd
(RFC5931).  I believe the document is Not Ready for the following

  1) The introduction and security considerations fails to acknowledge
  that password salting is not sufficient to protect against real-world
  password recovery attacks.  Iterative constructs are needed.  This
  knowledge is old, PBKDF2/RFC2898 (which is one standard technique to
  address the problem) was published in 2000 and has been widely
  deployed since then.  The document should mention this aspect.  There
  have been many successful attacks against pure-salted password
  databases in the real world, for example:

  2) Code points for the pre-processing techniques PBKDF2 (RFC 2898) and
  scrypt (RFC 7914) should be added, to support use of best security

  3) There are interop concerns with crypt() when discussion about which
  crypt algorithms (DES, MD5, etc) are to be used is lacking.  The page
  <https://en.wikipedia.org/wiki/Crypt_%28C%29> mentions a couple of
  algorithms, but several others exist out there.  Consider if the
  server tells the client to use an exotic crypt() schema like BSDi or
  NTHASH, and the client does not support this algorithm.  The document
  should discuss the sub-negotiation problem.  The document should
  mention what happens when the server choses an algorithm the client
  doesn't support.  The document should recommend that servers use
  widely-implemented schemas, like DES, md5, or sha256.

  4) Introducing a new pre-processing technique like OpaqueString+SHA1
  or OpaqueString+crypt() add complexity.  As far as I understand, there
  are no password databases with OpaqueString-processed passwords which
  are hashed with SHA-1 or crypt out there today.  Thus there is no
  interop argument for introducing the methods.  Please confirm that the
  intention is to introduce these methods as new ideas.  Then let me
  suggest that you only describe OpaqueString+SHA256 and skip
  OpaqueString+SHA1, OpaqueString+SHA512, OpaqueString+crypt.  This
  reduces complexity and does not cause a reduction of security.

Further, password databases with HTTP Digest MD5 passwords are widely
used.  For added legacy compatibility, consider support it too.  This is
not a show stopper, but failure to mentioning it in the context of
deployed password databases appears to me like an elephant in the room.
Where there conscious reasons for not including it?  It may be worth
stating those reasons in the document, if that is the case.