Re: [Cfrg] [saag] New draft: Hashed Password Exchange

"Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu> Thu, 05 January 2012 16:28 UTC

Return-Path: <prvs=2351dd59fc=uri@ll.mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD6E21F8767; Thu, 5 Jan 2012 08:28:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.45
X-Spam-Level:
X-Spam-Status: No, score=-4.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2cdrCpCCoDt; Thu, 5 Jan 2012 08:28:39 -0800 (PST)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id C306421F86D1; Thu, 5 Jan 2012 08:28:38 -0800 (PST)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id q05GSKc2015009; Thu, 5 Jan 2012 11:28:20 -0500
From: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
To: Steven Bellovin <smb@cs.columbia.edu>
Date: Thu, 05 Jan 2012 11:28:12 -0500
Thread-Topic: [Cfrg] [saag] New draft: Hashed Password Exchange
Thread-Index: AczLxwjthKWn6Sa0TTSjnfq/FJnchw==
Message-ID: <CB2B33EA.E5D1%uri@ll.mit.edu>
In-Reply-To: <4F054D78.1080008@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.12.0.110505
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3408607697_86656470"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2012-01-05_05:2012-01-05, 2012-01-05, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201050160
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [Cfrg] [saag] New draft: Hashed Password Exchange
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2012 16:28:40 -0000

Steve,

How would you compare your proposed localizing-by-URI approach with
localizing-by-host (or by "SNMP engine") approach proposed in RFC 3414
http://datatracker.ietf.org/doc/rfc3414/ ?

Some questions to consider.

You propose "localization" by service - i.e., by hostname + port. How many
passwords per user would a server store? How critical is your requirement
that "no two [effective] `passwords for different services [on the same
host] should be the same for the same user"?  A benefit of not localizing
based on the whole service would be the ability for a multi-named server ­
based on some rules that are out of scope for this email ­ choose the
"dominant" name and localize users' passwords to it, thus storing one
password per user on this server; avoiding the potential ambiguity that Joe
Touch pointed out.

Is HMAC an overkill in this case, considering that inverting a decent hash
didn't work even for the long-deprecated MD4 (we seem to worry here about
non-invertibility/one-way-ness, not collision resistance)? Or did you choose
it because it's the best keyed hash construct we have?  Note that the
brute-force attacks would be the same for both plain hash and HMAC (with
HMAC offering one more hash run per iteration).

Regarding salt ­ couldn't it be used on the server only? Treating the
"localized password" as the pre-salted password in the original Unix scheme,
then salting it before comparison? Obviously this is not the method to use
in protocols that employ the password derivative as a cryptographic keyŠ

Oh, and since this proposal seems to be addressing the same problem in a
somewhat similar way ­ perhaps it would make sense to include a reference to
RFC 3414 (section 2.6 Key Localization Algorithm)? :)

Tnx!
-- 
Regards,
Uri      uri@ll.mit.edu