Re: [saag] Improving the CHAP protocol

"Black, David" <David.Black@dell.com> Mon, 23 September 2019 19:30 UTC

Return-Path: <David.Black@dell.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 C75B21208D2 for <saag@ietfa.amsl.com>; Mon, 23 Sep 2019 12:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=PSRnXJ4s; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=EkD2Wdvl
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 8I9rBLMwMv8s for <saag@ietfa.amsl.com>; Mon, 23 Sep 2019 12:30:02 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (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 7BF6512085E for <saag@ietf.org>; Mon, 23 Sep 2019 12:30:02 -0700 (PDT)
Received: from pps.filterd (m0170395.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8NJFbfm015210; Mon, 23 Sep 2019 15:29:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=BrDcIXejPLd6w1wZ1d3u1OJGafx5FLbPP56x+ZMfxdA=; b=PSRnXJ4sa66orwZcqwdeXA9mEBxjdavAaU+4DbK58ZvtgUR/hDeHMsDOiZUJqZEOSg52 fy48o+Bmg2dpmT6MY93FQjAYESSm15xRjWMDCi+OrWtdZJ65qcfrjYvLRVdrluXv7uPB QPwjwz5s6+wZ2dymdHK9exBLcUcKBs3fO9tI2hSsGJd2xwWslNB14sPwOMrJws1QvndC wSIeIymTXRku7uFemWbzkys0OZ+OEPvP3bpKdjK8LVUMliYDntYpseA8Cqfqj4/t4MAn ZArrYFSzSwlCDqejRzh81+0PVhAf6qdfquHFo6ihnArkDL59grp7ML/U9uVQA/pMqI+l tQ==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 2v5ghm9d9y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Sep 2019 15:29:49 -0400
Received: from pps.filterd (m0142693.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8NJD7rd139275; Mon, 23 Sep 2019 15:29:48 -0400
Received: from mailuogwhop.emc.com (mailuogwhop-nat.lss.emc.com [168.159.213.141] (may be forged)) by mx0a-00154901.pphosted.com with ESMTP id 2v6188g53b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 23 Sep 2019 15:29:48 -0400
Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8NJTgaT022822 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Sep 2019 15:29:47 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com x8NJTgaT022822
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1569266987; bh=6OYtStFsxyaNkmaHMwpXcDf4TFU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EkD2WdvlCOO2li9gfsazfR2YX3B5K66c+On+PStxiIKlF9J6aVohovrQRVf5FLIkB lzefNzj3oeXDXK7hliX5eyioqd7FrpKXxICQ5H5rpSyBzqM5lP/sMSwLD2hnMUV8eJ 6cCUcznE7fyblvNpJO969HZkQcYadvTeTFCZoFuo=
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 23 Sep 2019 15:29:09 -0400
Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8NJT5Jf013961 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 23 Sep 2019 15:29:09 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0439.000; Mon, 23 Sep 2019 15:28:32 -0400
From: "Black, David" <David.Black@dell.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, "saag@ietf.org" <saag@ietf.org>
Thread-Topic: [saag] Improving the CHAP protocol
Thread-Index: AQHVbhyVNSLAH6mw10yrI1pLte3B86c2rMeAgAKtrQCAAEGFkA==
Date: Mon, 23 Sep 2019 19:28:31 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949363070E288@MX307CL04.corp.emc.com>
References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com>
In-Reply-To: <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-09-23T19:24:44.3760293Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [10.238.21.131]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-23_06:2019-09-23,2019-09-23 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 malwarescore=0 spamscore=0 bulkscore=0 priorityscore=1501 mlxscore=0 phishscore=0 adultscore=0 mlxlogscore=999 suspectscore=0 impostorscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909230164
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 bulkscore=0 phishscore=0 mlxscore=0 suspectscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909230164
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/9itYJ0BoCcb3gh2UCLLT1URL9Lw>
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: Mon, 23 Sep 2019 19:30:12 -0000

Hi Peter,

> > I think many people in this thread are missing the purpose of the exercise.

For clarity, the purpose of this exercise is to register additional hash functions for use by iSCSI, not to prolong the life of CHAP in PPP.  We have no problem asking IANA to restrict the newly registered hashes to be used only with iSCSI (i.e., prohibit their use with PPP).  One of the reasons that this is feasible is that iSCSI uses CHAP as part of an iSCSI-specific negotiation mechanism that is not based on PPP.

> > CHAP is used because umpteen bajillion devices and systems need it, not
> > because it's a very good protocol.  

I'm not sure whether iSCSI is up to a bajillion ;-), but there is a lot of iSCSI out there.  The situation that we can't change is that iSCSI references the IANA PPP CHAP registry for CHAP hash algorithms.  An important historical reason for that registry reference was compatibility with RADIUS verification of CHAP (which was important at the time).

> > 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.

FWIW, iSCSI CHAP is somewhat better than plain CHAP, e.g., checks that prevent reflection attacks are mandatory.

> > 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.

SHA-256 makes sense from that running code perspective, no problem.

> > 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.

I see no little to no current interest in a new iSCSI authentication protocol in either the storage standards community or iSCSI implementer community, whereas there is running iSCSI code for at least one of the new hashes.

Moreover, back when there was interest in iSCSI authentication protocols, what was wanted was a strong password protocol to defend against weak secrets (e.g., passwords).  iSCSI originally specified a version of SRP as optional, but that's not used much.  In 20/20 hindsight, it's unfortunate that IETF & CFRG missed the opportunity to recommend a preferred strong password protocol back around the time that the problematic patents were approaching expiration.

Thanks, --David

> -----Original Message-----
> From: saag <saag-bounces@ietf.org>; On Behalf Of Maurizio Lombardi
> Sent: Monday, September 23, 2019 6:30 AM
> To: Peter Gutmann; saag@ietf.org
> Subject: Re: [saag] Improving the CHAP protocol
> 
> 
> [EXTERNAL EMAIL]
> 
> Hello Peter,
> 
> Dne 21.9.2019 v 19:35 Peter Gutmann napsal(a):
> > 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.
> 
> That's correct, what we need is just a FIPS-compliant hash function
> that is very unlikely do be deprecated anytime soon; and we need it
> because the non-compliance of MD5 is breaking iSCSI use cases for our
> customers now.
> 
> The collision resistance of the hash function is not a top priority for us.
> 
> Personally, I would like to see adopted something widely used,
> SHA-256 and SHA3-256 are good candidates IMO.
> 
> Maurizio Lombardi
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag