Re: [saag] Improving the CHAP protocol

Alan DeKok <aland@deployingradius.com> Sun, 22 September 2019 13:51 UTC

Return-Path: <aland@deployingradius.com>
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 9309A12009E for <saag@ietfa.amsl.com>; Sun, 22 Sep 2019 06:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 PXGIoP2q0ODu for <saag@ietfa.amsl.com>; Sun, 22 Sep 2019 06:51:23 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A30120018 for <saag@ietf.org>; Sun, 22 Sep 2019 06:51:23 -0700 (PDT)
Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 6A9DB5C9; Sun, 22 Sep 2019 13:51:20 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <7DEB7775-B495-4269-AA60-386AD045BDAE@gmail.com>
Date: Sun, 22 Sep 2019 09:51:18 -0400
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Security Area Advisory Group <saag@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <58407786-6F26-45F5-90A0-0F42A7AF414D@deployingradius.com>
References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <7DEB7775-B495-4269-AA60-386AD045BDAE@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/AfaXnWNpQe_zfMILuFZV1-zsNiM>
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: Sun, 22 Sep 2019 13:51:26 -0000

On Sep 21, 2019, at 1:56 PM, Yoav Nir <ynir.ietf@gmail.com>; wrote:
> 
> FIPS is one advantage. The other is that MD5 is getting scarce in crypto libraries, while SHA-256 is everywhere.  Not everything is devices — there’s still software out there.

  MD5 will be used forever.  As will MD4.  Crypto library authors can complain, but the market has spoken.

  Every end user device ships with support for CHAP (using MD5) and MS-CHAP (using MD4).  These protocols are widely used as part of 802.1X authentication.

  The EMU WG spent years standardizing TEAP (RFC 7170, May 2014), which is only getting implemented now (!).  That method could have forbidden the use of insecure methods such as EAP-MD5 (CHAP) or EAP-MSCHAPv2.  It did not.  Even if it had deprecated MD5 / MD4 methods, no one implemented TEAP.

  In the mean time, people have been using EAP-TTLS and PEAP as "de facto" standards.  Which use MS-CHAP and/or CHAP.  The use of MD5 / MD4 is inside of a TLS tunnel so it's not all bad.  But the usage still makes it difficult to remove MD5 / MD4 entirely.

  It may take 3 years to get a new standard which deprecates the use of MD4 / MD5 in authentication methods.  It will then take another 10 years before the new standard is wide-spread.  Only then can these insecure authentication methods be disabled on authentication servers.

  I see deprecating MD5 / MD4 as "pie in the sky" wishful thinking.  It's definitely *required*, but entirely *impractical*.  Crypto libraries *will* ship with them for the next 15 years.  If they are removed from crypto libraries, vendors will add their own MD5 / MD4 implementations to every end-user device.

  If we wanted to fix this, we should have been done it years ago.  Maybe we can start the process now.  But to be realistic, I will be in retirement long before MD5 / MD4 are removed from common usage.

  Alan DeKok.