Re: [http-auth] Why update Digest Auth?

"Henry B. Hotz" <hotz@jpl.nasa.gov> Sun, 21 July 2013 23:33 UTC

Return-Path: <hotz@jpl.nasa.gov>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3C21F9AFE for <http-auth@ietfa.amsl.com>; Sun, 21 Jul 2013 16:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 viEYJJ6hMrfN for <http-auth@ietfa.amsl.com>; Sun, 21 Jul 2013 16:33:15 -0700 (PDT)
Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.106]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4C421F9B58 for <http-auth@ietf.org>; Sun, 21 Jul 2013 16:33:15 -0700 (PDT)
Received: from laphotz.jpl.nasa.gov (laphotz.jpl.nasa.gov [128.149.133.44]) (authenticated (0 bits)) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r6LNXBDG013832 (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits) verified NO); Sun, 21 Jul 2013 16:33:12 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: "Henry B. Hotz" <hotz@jpl.nasa.gov>
In-Reply-To: <51EABBDB.2090401@gmail.com>
Date: Sun, 21 Jul 2013 16:33:11 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A55E05C5-2027-4B74-BD69-71B1A0CFB2AA@jpl.nasa.gov>
References: <51EABBDB.2090401@gmail.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
X-Mailer: Apple Mail (2.1508)
X-Source-Sender: hotz@jpl.nasa.gov
X-AUTH: Authorized
Cc: HTTP Auth WG <http-auth@ietf.org>
Subject: Re: [http-auth] Why update Digest Auth?
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Jul 2013 23:33:20 -0000

I won't claim to know the future, or even everything about the present, but I agree with the goal of getting a "digest-v2" with the properties you suggest.  If this group can reach consensus on such a thing fast enough to leverage some of the resources that might otherwise go to less ambitious updates to digest, I'm all for it.

Is that a realistic possibility?

On Jul 20, 2013, at 9:33 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

> Sorry for questioning the group's charter, but this keeps bugging me:
> 
> I'm assuming this WG will publish two Standards Track RFCs, updating Basic and Digest Auth. And a pile of Experimental RFCs with all sorts of lovely state-of-the-art crypto.
> 
> Enterprises will require vendors to implement the updated Basic and Digest, and in a few years' time we will end up with the worlds' browsers and Web servers supporting Basic and Digest Auth with I18N and (for Digest) crypto agility. Almost nobody will implement the other drafts.
> 
> In addition, the websec WG will hopefully work on "session continuation", which will extend the authentication to the whole session in a better way than cookies, and will provide channel binding. Assuming much of the Internet's traffic will remain unencrypted for years, this will be "good enough" security for this traffic. But, it won't work with Digest (because it is not "key generating", to borrow an EAP term).
> 
> Now my question: we are telling implementors to upgrade Digest to gain I18N (and the algorithm agility, which in this case is mostly security theater, because when using short passwords we remain vulnerable to a dictionary attack anyway). Why not tell them *instead* to move to Digest-v2, which is dictionary attack resistant? Digest-v2 could be based on EKE or SRP, or maybe on draft-oiwa-http-mutualauth, and will support session continuation.
> 
> Seems to me this would be a much better use of our time, as well as implementors' energy.
> 
> Thanks,
>    Yaron
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu