Re: [saag] Improving the CHAP protocol

John Mattsson <john.mattsson@ericsson.com> Sun, 22 September 2019 16:44 UTC

Return-Path: <john.mattsson@ericsson.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 CCC89120059 for <saag@ietfa.amsl.com>; Sun, 22 Sep 2019 09:44:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.027
X-Spam-Level:
X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 S8_wZAe1Yg1h for <saag@ietfa.amsl.com>; Sun, 22 Sep 2019 09:44:09 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80081.outbound.protection.outlook.com [40.107.8.81]) (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 79EA1120047 for <saag@ietf.org>; Sun, 22 Sep 2019 09:44:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lZ7KTdbJnkyj/mM4qNdVwEGgGnms/WbO9h/+zdwIrIjPluz604CjxxwdsY8+TrH4ZP7urPcsjrLRQVPR+y7Zn9VOj3j0h3b4WIeOiAu+E310U4bbjQuaT62Wu1tz8sPdhP87w8CS/xwN0DDNkbyRaReGKAJJHGkkwEYNbrJGiMB1Bmk3HsPH6cg6eNCpoLS9Rnq4yDn/eeZuW7TbqwzTtlv78UzaKt/6pjdeyrotZPVObf6zJ+KRnyH8Gxaedi0q0RciGWLvXEqJnGN3MWT9OKvsqBVsFjBmvtUjPNslNZHmnYXu4ENqrZWUCy6fatSghh087KQziWU/uvrOygI0ig==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EBpNBQILQCD2HLkLHzwfzB16y9pNdAW2f+5M0dbMH3k=; b=iohGim2UOf14E6NRz0W0+gEnDNz+oyVOb6fiVFTsWzawwiOe5cnJkpMi5YrKQ26RnbQvMSj98WqP1Xm2Ab7Z0s9KyxPvlWyUsT50RsM8X33VXbtL73DHF2IWwZjAWm3dcxaj9uHX5vngqUXeC/M6LCUoSoaa0xfMA3lPf3X+EwDHcmkkelVjg09fZ/eXn0x5a3CZFtDwHEG7I/5zSwjeVbFocI5conm9KN4cbk7CkRzAEsD1PNZjc74RSk/S7jDxRFyiQD5vBBjkRLqI4RCJHS/U6deqhyPfMjzmkzlrVPmIv9fa3mrjNne70+OHGYrj/5p4cOT0KOrGDL4bRUGymQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EBpNBQILQCD2HLkLHzwfzB16y9pNdAW2f+5M0dbMH3k=; b=KVg0/zTHxfKA1D3AfKkLzLkxUoix0qD2CCzXf4zjl6UtDrRISnn/Shr3tkAnqf8kAEKvw0yDdur1BgOPyV85ANle1W9Iy2BF9nKPlniRqL4DsSdh5gQFWdbDYLmpb9cjP4HI4PAZTGe7Cr6LswUBxnJ6fuiUIVPUuqXw9RxEajA=
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4332.eurprd07.prod.outlook.com (20.176.168.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.10; Sun, 22 Sep 2019 16:44:06 +0000
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2284.023; Sun, 22 Sep 2019 16:44:06 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Alan DeKok <aland@deployingradius.com>, Yoav Nir <ynir.ietf@gmail.com>
CC: Security Area Advisory Group <saag@ietf.org>
Thread-Topic: [saag] Improving the CHAP protocol
Thread-Index: AQHVbhyYCYcHWGngr0yyn5sVfxkQYac2abmAgAAFwoCAAU3pAIAAUc6A
Date: Sun, 22 Sep 2019 16:44:06 +0000
Message-ID: <C446663A-3E07-4958-8923-380709F0D4FB@ericsson.com>
References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <7DEB7775-B495-4269-AA60-386AD045BDAE@gmail.com> <58407786-6F26-45F5-90A0-0F42A7AF414D@deployingradius.com>
In-Reply-To: <58407786-6F26-45F5-90A0-0F42A7AF414D@deployingradius.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [82.214.46.143]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 4f04d90c-652c-42e8-c22e-08d73f7c1586
x-ms-traffictypediagnostic: HE1PR07MB4332:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <HE1PR07MB43320CC310E19D0E013B3A0E898A0@HE1PR07MB4332.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 016885DD9B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(136003)(366004)(39860400002)(189003)(199004)(13464003)(478600001)(102836004)(229853002)(6506007)(53546011)(110136005)(58126008)(6246003)(76176011)(81156014)(2616005)(186003)(446003)(966005)(14454004)(81166006)(26005)(8676002)(11346002)(66066001)(99286004)(33656002)(25786009)(4326008)(8936002)(7736002)(305945005)(256004)(3846002)(6116002)(14444005)(486006)(71190400001)(6436002)(5660300002)(71200400001)(91956017)(76116006)(66446008)(64756008)(66556008)(66476007)(6486002)(44832011)(6306002)(6512007)(2906002)(316002)(36756003)(476003)(86362001)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4332; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: eT5FlGR5xYzOiBjbVvM5DTHxGokUMwNf/KA9BJ1aB7PvnfK8UgxPJ5Z5UV75PEClY7Vbu6alf+n9BkAGO/ajjvhJMZSrQa8Qe6kbFlmdcdi5RZxosOLjTyT8FuW60FvhRmUgmxzWyXkzoI4HfvAIrCAT0p4hBcNOpdilel1hSpos3LsCZ9RvDM6FevwjQU6G35xLtu+3BkmCB+OU0RIBNfLTGcc5S/49wcu85uoM+hMN4RlPzyqvV5AkWVt/YCQyF0vqsUz3Z96UbK0XZTiURjI2aiYLgekFf65d0PPmpwZvwPU497lNOwNSuxbmcADHwrcyG+fokawMdybe53Qx+TrzJVHQREXtdB5XRm+fUAFfcmyDpsG8TePZ1UcDZrwERhKNJygSzFuPbSnVYKCYJ0YoZHUG7/ToyT3Ohwm+iyE=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <399C9EF5569F334088267EE496DBBCAD@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f04d90c-652c-42e8-c22e-08d73f7c1586
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2019 16:44:06.4583 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mJcTDPCuXVGkP63AvYRVMUAP2Cv8FMVfSfc63WWbwQKs7N++qwYB/sOlUIz10Hv1qnek1+5ursoDJTzUiaounxi2KbJBb+0jam8QoXt8Apw=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4332
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/WZJJ2ANFGZsezL19Pv7RC09VPdg>
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 16:44:13 -0000

Hi,

I fully agree that it should have been done a long time ago and that it will take a very long time to achieve. To me that just means we need to start as soon as possible.

When it comes to crypto profiling, IETF is often very slow and very focused on whether some system will continue the weak algorithms in questions. For an example take the otherwise excellent RFC 7525 that has several super soft statements like:

"Curves of less than 192 bits SHOULD NOT be used."

I have met several implementors in different companies that read "SHOULD NOT" as "NO REASON TO CHANGE ANYTHING".

I think IETF in general need to be much more pro-active when it comes forbidding weak algorithms and also use much more "MUST NOT".

Cheers,
John

-----Original Message-----
From: saag <saag-bounces@ietf.org>; on behalf of Alan DeKok <aland@deployingradius.com>;
Date: Sunday, 22 September 2019 at 15:51
To: Yoav Nir <ynir.ietf@gmail.com>;
Cc: Security Area Advisory Group <saag@ietf.org>;
Subject: Re: [saag] Improving the CHAP protocol

    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.
    
    _______________________________________________
    saag mailing list
    saag@ietf.org
    https://www.ietf.org/mailman/listinfo/saag