Re: [saag] Improving the CHAP protocol

Peter Gutmann <> Sun, 22 September 2019 19:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57CBA12002E for <>; Sun, 22 Sep 2019 12:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Status: No, score=-4.197 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r34fE8M76FTz for <>; Sun, 22 Sep 2019 12:53:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6F0E120090 for <>; Sun, 22 Sep 2019 12:53:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1569182023; x=1600718023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/Hossy2Qucn+Q4LXpnFKxixWg0/JZ0nHLSWyGhVvZK4=; b=oGpg3XNffUNhwlifmPonfo+hEPDxXwAAGy8r907PHEeUx1C5sg34miUM mLKxZs+Wmm6IHSlhhfNV3pp6xQrknl3OIIuQZz1yUaa9c/xcyBFfmOCZi +PrghX0z3OHuMZoZ+8iUVwYRf/AI51PYrLBJjx/eajxR14beHai2lR6kU WhFnRZSLBfiRvU54HyT2+Ib/t5jyYQ6LLS8UTT5MVAFuUwS7AytKjv1s1 L/d8a4XW9VM0Mp8RrtoebqGVKntgWsKFMecWpbv8fIAzN/zqcKE8kpQxx YykYS3s29ibJbSVoHGqvTig27f9KEJnE2NRQvCkKm37463vgocrZ/8csK g==;
X-IronPort-AV: E=Sophos;i="5.64,537,1559476800"; d="scan'208";a="87216566"
X-Ironport-Source: - Outgoing - Outgoing
Received: from (HELO ([]) by with ESMTP/TLS/AES256-SHA; 23 Sep 2019 07:53:39 +1200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 23 Sep 2019 07:53:39 +1200
Received: from ([]) by ([]) with mapi id 15.00.1395.000; Mon, 23 Sep 2019 07:53:39 +1200
From: Peter Gutmann <>
To: Alan DeKok <>, Yoav Nir <>
CC: Security Area Advisory Group <>
Thread-Topic: [saag] Improving the CHAP protocol
Thread-Index: AQHVbhyc2Z4QK0TjfkKunwtzmsdiH6c2aPb+//89WoCAAU3qAIABLjYk
Date: Sun, 22 Sep 2019 19:53:38 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [saag] Improving the CHAP protocol
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Sep 2019 19:53:47 -0000

Alan DeKok <>; writes:

>In the mean time, people have been using EAP-TTLS and PEAP as "de facto"

Yup.  Doesn't matter how bad the auth protocol actually is because it's
tunneled over TLS everywhere where it matters.

>I see deprecating MD5 / MD4 as "pie in the sky" wishful thinking.  It's
>definitely *required*, but entirely *impractical*.

Definitely.  And that's why I proposed having the replacement RFC titled as
"FIPS compliance for CHAP", because moving to SHA-256 won't make it more
secure, it'll just make it more FIPS compliant.

Having said that, if you're going to go with a breaking change in CHAP, you
may as well actually fix CHAP rather than just making the hash function FIPS
compliant.  There's a rather nice mutual auth protocol from Kaufman, Perlman,
and Speciner which is something like:

Challenge ->
<- Enc( Challenge )
Enc( Response ->

using the universally-available AES, so the whole protocol is two crypt
operations on each side.  It's one more message than CHAP, but provides mutual
auth in the process.  Downside is that for low-entropy keys/authenticators
it's open to a brute-force attack, but it is a starting point.