[saag] Improving the CHAP protocol

Maurizio Lombardi <mlombard@redhat.com> Wed, 18 September 2019 12:25 UTC

Return-Path: <mlombard@redhat.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 D73161201E5 for <saag@ietfa.amsl.com>; Wed, 18 Sep 2019 05:25:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 AfuDOlXBxvf8 for <saag@ietfa.amsl.com>; Wed, 18 Sep 2019 05:25:28 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBD812004D for <saag@ietf.org>; Wed, 18 Sep 2019 05:25:27 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ACB7810C0928 for <saag@ietf.org>; Wed, 18 Sep 2019 12:25:26 +0000 (UTC)
Received: from [10.35.206.36] (unknown [10.35.206.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id EA0C81048134 for <saag@ietf.org>; Wed, 18 Sep 2019 12:25:25 +0000 (UTC)
To: saag@ietf.org
From: Maurizio Lombardi <mlombard@redhat.com>
Message-ID: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com>
Date: Wed, 18 Sep 2019 14:25:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.66]); Wed, 18 Sep 2019 12:25:26 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/oIYazpXoc0hyugmAN-2SI6ZlpFo>
Subject: [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: Wed, 18 Sep 2019 12:28:17 -0000

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