[saag] Improving the CHAP protocol - conclusion

"Black, David" <David.Black@dell.com> Fri, 27 September 2019 18:23 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D248812091D for <saag@ietfa.amsl.com>; Fri, 27 Sep 2019 11:23:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 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, URIBL_BLOCKED=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=Qpu2hnaW; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=fny4R5gf
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3ioF1op9Yasq for <saag@ietfa.amsl.com>; Fri, 27 Sep 2019 11:23:16 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com []) (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 3EBC312090D for <saag@ietf.org>; Fri, 27 Sep 2019 11:23:16 -0700 (PDT)
Received: from pps.filterd (m0170398.ppops.net []) by mx0b-00154904.pphosted.com ( with SMTP id x8RHxwfh013570; Fri, 27 Sep 2019 14:23:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=YxB2wPZkWjbza5bj8s4oVK/LdsYu93uBnPVxCxdrkLE=; b=Qpu2hnaWFgxJWUuaXBO0BijpxTN168Eqn1aWPGwthWqGeQszNEZ5K29lW1+O3f0IVO9d 1FIsAMGRlshxbef0k/H45ehaRILitSKC3l7v7cgB/3cbTuf2YGS579yztoz6A1MinN9A 5hGXw/f7DYhwAu4FgUlKVZwO3kjQGa2aPNxWjOTe/uG9RZ7/MknesMwpIPLR2+jR6vMn Tgf0mLbJBjo5y+xpopJnHj/fCwDGwlrkwNwWG2WkAWy3btydEuVHuc0jRmrVhouB5ZTa K52wnvrJRtiKbkN61vLCgbmDoX1/ZjVDr58SAClDPvzGQWVCFvg1DTx5tx8GGilkVy7d Qw==
Received: from mx0a-00154901.pphosted.com (mx0b-00154901.pphosted.com []) by mx0b-00154904.pphosted.com with ESMTP id 2v5f3b054x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Sep 2019 14:23:15 -0400
Received: from pps.filterd (m0089484.ppops.net []) by mx0b-00154901.pphosted.com ( with SMTP id x8RI3raQ053547; Fri, 27 Sep 2019 14:23:14 -0400
Received: from mailuogwhop.emc.com (mailuogwhop-nat.lss.emc.com [] (may be forged)) by mx0b-00154901.pphosted.com with ESMTP id 2v989w9qrp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 27 Sep 2019 14:23:14 -0400
Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com []) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8RINCdj008428 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Sep 2019 14:23:13 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com x8RINCdj008428
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1569608594; bh=4732iXrQNLT3lIozZFIqvoin1bY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=fny4R5gfmDczT23ZcClsetu1So15y8kPwflWiFN+ST6zwLPbJPYflU4SPqOjoPtW9 qfq9TjB27VWOuAHZ4hyNQev9JlKBn4B/3aNQqJdtD9DI7wb+i7kl2ATCo65FgakKOZ 9CZN12IWEGqSfz2kdpVNr6A6iP28+oGWfN0g+0qU=
Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com []) by maildlpprd06.lss.emc.com (RSA Interceptor); Fri, 27 Sep 2019 14:22:52 -0400
Received: from MXHUB312.corp.emc.com (MXHUB312.corp.emc.com []) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8RIMqZ8026321 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 27 Sep 2019 14:22:53 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB312.corp.emc.com ([]) with mapi id 14.03.0439.000; Fri, 27 Sep 2019 14:22:52 -0400
From: "Black, David" <David.Black@dell.com>
To: Maurizio Lombardi <mlombard@redhat.com>, "saag@ietf.org" <saag@ietf.org>
Thread-Topic: Improving the CHAP protocol - conclusion
Thread-Index: AdV1YI7WvMgpiyJvSUaFhAD5cVGTUg==
Date: Fri, 27 Sep 2019 18:22:52 +0000
Message-ID: <CE03DB3D7B45C245BCA0D2432779493630727333@MX307CL04.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
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-27T18:22:19.7795331Z; 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: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd02.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-27_08:2019-09-25,2019-09-27 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 bulkscore=0 impostorscore=0 adultscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909270150
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 impostorscore=0 spamscore=0 phishscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 clxscore=1015 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909270150
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/Ctku5bIluYoVrPRsJdTVz6luYxc>
Subject: [saag] Improving the CHAP protocol - conclusion
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: Fri, 27 Sep 2019 18:23:19 -0000

I'm responding to Maurizio's original message to explain what we (Maurizio and yours truly) are going to do and why.  First of all, we want to thank everyone who contributed to this productive discussion.

The TL;DR conclusion is that we will ask IANA to register SHA-256 (from the SHA2 family) and SHA3-256 (from the SHA3 family).  Peter Guttman stated the fundamental reason for registering these basic members of each hash family better than I could:

> 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 the primary reason to register SHA-256 in preference to SHA-512/256 and to register SHA3-256 in preference to SHAKE256.

For SHA2 hashes, the message extension attack that motivated development of SHA-512/256 does not appear to be relevant to CHAP, at least as used by iSCSI.

For SHA3 hashes, a registration of SHAKE256 would have to include an output size (d), which would be 256 bits.  For a 256 bit output, the difference between SHAKE256 and SHA3-256 turns out to be whether '01' (2 bits) or '1111' (4 bits) is appended to the input before running the core Keccak hash calculation [1], which (while important to distinguish use of those two hashes) seems to lack any serious security or crypto difference.  In addition, the Linux kernel (location of an immediately important iSCSI implementation) has running code for SHA3-256, but not for SHAKE256.

[1] https://en.wikipedia.org/wiki/SHA-3#Instances

Once again, many thanks to everyone who contributed, --David
David L. Black, Senior Distinguished Engineer
Dell EMC, 176 South St., Hopkinton, MA  01748
+1 (774) 350-9323 New    Mobile: +1 (978) 394-7754

> -----Original Message-----
> From: saag <saag-bounces@ietf.org>; On Behalf Of Maurizio Lombardi
> Sent: Wednesday, September 18, 2019 8:25 AM
> To: saag@ietf.org
> Subject: [saag] Improving the CHAP protocol
> Hello,
> I am working to solve the problem of FIPS (Federal Information Processing
> Standards)
> compliance with the iSCSI/CHAP authentication protocol.
> CHAP is described in RFC 1994: https://tools.ietf.org/html/rfc1994.
> This email is to start discussion, and look for guidance.
> All the major implementations of CHAP for iSCSI use MD5 as the only
> supported hash function.
> Unfortunately, MD5 is now considered insufficient for FIPS and isn’t allowed
> it to be used on FIPS-enabled systems.
> As a consequence, when FIPS mode is active, the CHAP authentication
> doesn’t work.
> As reported by IANA, the SHA1 algorithm could be used as an alternative to
> MD5:
> https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xml#ppp-
> numbers-9
> but the use of SHA1 on FIPS systems has been deprecated and will soon be
> phased out.
> I therefore proposed to add a more modern hash algorithm (like SHA3-256)
> to the list of approved CHAP authentication algorithms.
> David Black suggested to consider adding SHA-256 and SHA-512/256 in
> addition to SHA3-256
> and asked me to send an email to this mailing list:
> David Black wrote:
> -------------
> My sense of the IETF view on secure hashes is that MD5 and SHA1 are
> broken, whereas \
> the SHA2 algorithms are proving to be longer-lived (more resistant to attack)
> than \
> expected, and the SHA3 algorithms are fine.
> That suggests that registration of codepoints for both SHA2 and SHA3 would
> be a good \
> thing to do, as opposed to only SHA3.  I'd suggest starting with either SHA-
> 256 or \
> SHA-512/256 (both are SHA2 hashes) in addition to SHA3-256, as all three
> have the \
> same 256-bit output size.
> Figuring out exactly what should be done here (e.g., which SHA2 variant to
> register) \
> would benefit from some discussion at IETF.  I would start with the Security
> Area's \
> saag@ietf.org mailing list.  In addition, as iSCSI falls within IETF's Transport \
> Area, the Transport Area Directors ought to be looped in beforehand.
> -----------
> https://marc.info/?l=target-devel&m=156755533912350&w=2
> Thank you,
> Maurizio Lombardi
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag