Re: [saag] Improving the CHAP protocol

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sat, 21 September 2019 17:35 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A17A120071 for <saag@ietfa.amsl.com>; Sat, 21 Sep 2019 10:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxfR0ZAdKgeS for <saag@ietfa.amsl.com>; Sat, 21 Sep 2019 10:35:41 -0700 (PDT)
Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 B728812004C for <saag@ietf.org>; Sat, 21 Sep 2019 10:35:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1569087341; x=1600623341; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Ulk9YZXjXlnYxYHhHXLNzTyJb9y8RmNCkoAYnYJqd2k=; b=GaeAP8FHCNEQD8QJGIIVsYZ+7MOshdj2UkZMHOp16t8IAN0na28UfWva NQC5VLVi/56QruhB1Yx9ESS2aM+MsyIGF4jmIqe03ZCrTVACGpIz5Osvf 19TjtS3y2UZnxhzlD287PaQXUMCrydqdKDqlDXo2TXp/GKtVkH7xKSroy hBw1enZxvInJdEDwcmcf9Hz5fgl+4h5KHsg1GYWYfcfBzSwdkhphPq+Ys qhNKr15h0KKNtnHwXh7lsJ+7OAaiV99VoM2RG6EgLVoJ2P+tVzSkKkKAO 26YZIB5e7zot4FBJDnqkxnARkQIS38/rmZdyIwfZa1dLPyc5oxfHedwps w==;
X-IronPort-AV: E=Sophos;i="5.64,532,1559476800"; d="scan'208";a="86956245"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing
Received: from uxcn13-ogg-d.uoa.auckland.ac.nz ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Sep 2019 05:35:38 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 22 Sep 2019 05:35:36 +1200
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sun, 22 Sep 2019 05:35:36 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Maurizio Lombardi <mlombard@redhat.com>, "saag@ietf.org" <saag@ietf.org>
Thread-Topic: [saag] Improving the CHAP protocol
Thread-Index: AQHVbhyc2Z4QK0TjfkKunwtzmsdiH6c2aPb+
Date: Sat, 21 Sep 2019 17:35:35 +0000
Message-ID: <1569087342890.52733@cs.auckland.ac.nz>
References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com>
In-Reply-To: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/m6XIjnmCf5qhZLX93iOdkOvfOMo>
Subject: Re: [saag] Improving the CHAP protocol
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Sep 2019 17:35:44 -0000

I think many people in this thread are missing the purpose of the exercise.
CHAP is used because umpteen bajillion devices and systems need it, not
because it's a very good protocol.  It's insecure because it's CHAP, not
because it uses MD5.  Since it needs a one-way function, not a collision-
resistant function, any hash function is as good - or bad since CHAP isn't
very secure - as any other.  Switching from MD5 to polyquantumresistantind-
ccaprovable2048bithash will make no difference whatsoever to its security.

What the original poster asked for is something FIPS compliant.  If you want
to convince said umpteen bajillion devices to switch, you'd better use the
universal-standard FIPS-compliant hash algorithm that everything supports,
which is SHA-256, not a bunch of wierdo fashion-statement algorithms that
nothing supports, which is most of the other stuff that's been suggested.

Having said that, you'll have to accept that the vast majority of users will
keep going with MD5 more or less forever since there's no motive apart from
FIPS to change, so perhaps it'd be best to pitch the update RFC as "FIPS
compliance for CHAP" or something similar.

Peter.