Re: [radext] Proposed charter text based on IETF-115 BoF

Paul Wouters <paul.wouters@aiven.io> Thu, 24 November 2022 03:21 UTC

Return-Path: <paul.wouters@aiven.io>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE08C14F743 for <radext@ietfa.amsl.com>; Wed, 23 Nov 2022 19:21:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=aiven.io
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZNLLtRf-_r-W for <radext@ietfa.amsl.com>; Wed, 23 Nov 2022 19:21:52 -0800 (PST)
Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4F8C14F606 for <radext@ietf.org>; Wed, 23 Nov 2022 19:21:52 -0800 (PST)
Received: by mail-wr1-x42e.google.com with SMTP id cl5so584976wrb.9 for <radext@ietf.org>; Wed, 23 Nov 2022 19:21:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=gnhCkKUVQ8imPLLAXwWSsC2P5hh7ytGc/erHq1oLbMk=; b=ru5a04On3OlDhrqLYiLR5HMPJXNcth2VdIjyanSCqEC0nmho+ui067Ne0U1JUjMR/5 oVbo3v4rUf4y9ea6x9FX5JjXFJhuOxYDtS552T1a4mzwUAoAESpI3NR/ixmqdIoP++jd 5Uo/5xfHnqLafk/Eh7C6FJ2FdwEs0WGvps5x4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=gnhCkKUVQ8imPLLAXwWSsC2P5hh7ytGc/erHq1oLbMk=; b=ZvBUudulmhWSFeeYHf8iNv1jJmoLR7eWQ7qcuTzt/FsFJtsXzNtBTTgDfnq5iM0KLA ynmla1jl/3ZMUr5fLWycoAbwcLVhiGaOby2IzqcOQKiUfPzWggmUSCXS83+tQuclRIc/ nRrlCKMdtM65gfa0Brksjm5s0jJKFjZIdzVU39w+ZAKkqtOR9o92/X2YOtSbfD0rFxjD UXYA5LiwbXhWR6EaZleIHbdrR45R+w0LCgmlGIpjOj/drkOBjHu9LOQ8oFatVn/CqtAi KkV9BzsZYuSLoMHFoYxRaScGn89F5D6WRCY2iGj01KPtMiDyZmWCuXvtWBxGu09GdAzM kn5g==
X-Gm-Message-State: ANoB5pngVMsDlQ8NJ2IB6mlNv/Vgm6rFW9vWNzBgkvvr2d0kHEdP+3zx /f5inZgpUwGiLjNk9kbNXXkO5Xt3kck1zsi2m6xffg==
X-Google-Smtp-Source: AA0mqf6R2I/YUVJiXawS+w6HIeqq39k2NvaQ3jQEtbXrF+APY7VTJk9hIcY3har5Tx3+QFvDoiIRRJJXZ+nmNL0kfqA=
X-Received: by 2002:adf:e6c4:0:b0:241:dae2:431f with SMTP id y4-20020adfe6c4000000b00241dae2431fmr9257343wrm.261.1669260110287; Wed, 23 Nov 2022 19:21:50 -0800 (PST)
MIME-Version: 1.0
References: <FD0507D4-2C1D-478A-97E0-ECEEF1A5613B@deployingradius.com> <E82B0ECD-4580-4F35-B07B-35685CFC5C44@aiven.io> <883f3572-121f-5ed8-7378-1a91c5525f88@iea-software.com> <EAAC2507-5D29-4453-8881-BC8D9D5314D8@deployingradius.com> <4ce6d292-bb34-5dd7-7b8b-d43c282658f1@iea-software.com>
In-Reply-To: <4ce6d292-bb34-5dd7-7b8b-d43c282658f1@iea-software.com>
From: Paul Wouters <paul.wouters@aiven.io>
Date: Wed, 23 Nov 2022 22:21:39 -0500
Message-ID: <CAGL5yWbd3u+eUqe8vNZ-qKiQt+vr+jHGqtmQpskW-PwCNrYD5g@mail.gmail.com>
To: Peter Deacon <peterd@iea-software.com>
Cc: Alan DeKok <aland@deployingradius.com>, Bernard Aboba <bernard.aboba@gmail.com>, "radext@ietf.org" <radext@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e979ac05ee2ee72f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/zwm30Ma2hZcc_ZP0cG06Qm1ykZo>
Subject: Re: [radext] Proposed charter text based on IETF-115 BoF
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Nov 2022 03:21:56 -0000

On Tue, Nov 22, 2022 at 11:56 AM Peter Deacon <peterd@iea-software.com>
wrote:

>
> Is anyone aware of a specific reference to specific text of either FIPS or
> similar standards that say MD5 can't be used for any purpose?
>
> Here is an implementation guide for FIPS 140-2 that is the closest
> thing I've ever been able to find that speaks to this specific issue.
>
>
> https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/fips140-2/fips1402ig.pdf
>
> pg95 "non-approved cryptographic algorithms may be used in the approved
> mode of operation if the non-approved algorithms are not a security
> function. "
>

Note that the MD5 usage in Radius is a security function.

I've worked a lot with the people from ATsec, a NIST certified lab that
validates FIPS modules.

This is what Stephan Mueller from atsec confirmed to me:

As stated below, MD5 is a non-approved algorithm. Thus, if Radius requires
> MD5, it uses non-approved crypto and may not be used where
> FIPS-jurisdiction
> is in effect (or the crypto officer gave an exception based on his risk
> analysis).
>
> For a FIPS module, however, it is permissible to offer non-approved
> cryptography including MD5, provided the following constraints are met:
>
> - the service indicator references the non-approved algo as non-approved
>
> - the non-approved algo does not share a key / CSP with an approved
> algorithm
>
> As MD5 does not use a key, all that is needed by a FIPS module is to have
> a
> service indicator as mentioned.
>
> The one and only exception for MD5 being allowed is when it is used for
> the
> TLS1.1 KDF where it is used in unison with SHA-1.
>
>
> Bottom line:
>
> - your crypto library may provide MD5 along with the non-approved indicator
>
> - Radius would use non-approved crypto and thus would not be allowed to be
> used [in FIPS mode]
>

This means (and this is what people concluded in the past) is that wrapping
Radius
in TLS, where the TLS layer only uses approved algorithms, is not good
enough for FIPS.
The inner radius packets are still used to make authentication decisions
based on security
methods that uses MD5, which is not allowed for FIPS.

Paul