Re: [radext] BoF request for IETF 115

Bernard Aboba <bernard.aboba@gmail.com> Thu, 22 September 2022 21:51 UTC

Return-Path: <bernard.aboba@gmail.com>
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 72DD9C14CE30 for <radext@ietfa.amsl.com>; Thu, 22 Sep 2022 14:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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, FREEMAIL_FROM=0.001, 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 (2048-bit key) header.d=gmail.com
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 kqRqvor3dfbk for <radext@ietfa.amsl.com>; Thu, 22 Sep 2022 14:50:59 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 033A9C1524D7 for <radext@ietf.org>; Thu, 22 Sep 2022 14:50:18 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id y8so15466248edc.10 for <radext@ietf.org>; Thu, 22 Sep 2022 14:50:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date; bh=9dEmfff1oKCspqFRAhpnH9dAcZsXJUnQFZ5Rx9p5t/4=; b=PwVc7L/yV7JaoHGfhhQ2+wMjO/Uj5i6A7eODEZA+wzId5eG6gPDNmIka9ygsCP3FXa aOlSCkz3P3kRdpVwNDS75GF8d9Zwq1lwLdoD9mun+yRqiVUuh4bd96atboJErgU1/4Gj N/E0CmiPzpoyipH6Ek3cAfN9eKSlGBj4RKCNVUgp9im//e9YWKE23OJBUvEjpbdpI4cV Qgf+q1HzDrNnUtsvaGROjPsD0TqfObH2DdAV/VDkrg0BHfLSxB5ZAhGk44BLuo7qYgop t0d5vpzQHxOFvzQvE1DsG2Dx7SSHZahSCZql5eSwANmMi1/+tFmFBeQmlaZ/3cZcj6NM Of2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=9dEmfff1oKCspqFRAhpnH9dAcZsXJUnQFZ5Rx9p5t/4=; b=FLI0p+r/3t80VEzsAWfCAlJH7sc7b3vE924hWJ1+9WPui0vUVLu6Ytu93FgVgoIZgE LxsFyfFpiCjkg865/LxK2J1lGPTHTPpy5mY7gjS7sZ5uXE+WHybhEf58VHG1/FPSkIxo 9xo78y+eU1R0jLZwuWyRKks8cvb37o6JHVkR+U0733zTkT5sbz5/SRAyuMSCHhVVi+Fc KaMiwD9unaPwO3EtlP21dBVE2OugznByq6PIIEaAOZQa8beBGNURp405OxeUifQOz62m CpqqvW+DjoLCwOZPGhIfGNcr4yeTzWxbFBPp3UlFafaIhSnYt1k5F2KdUznwmirn+1hb SelA==
X-Gm-Message-State: ACrzQf3hRX454ZsUab7AmBe/nDOhgVvcKwyi2RQ1Q5VnsBRAUztQmaXA bwuIJdHU3ZogJNmnAXWux5oHZdmJzioHSqoXu91ncE+kLlCAiQ==
X-Google-Smtp-Source: AMsMyM5S5O72adddETipOG7Nz+BU/NmFxSR7KXBPyGJKjDI+iid9R52XGDln1hLhmw2AQ3M9o07lQPRDSgMALYOXPWo=
X-Received: by 2002:a05:6402:ca9:b0:44e:d8f3:3d0e with SMTP id cn9-20020a0564020ca900b0044ed8f33d0emr5219599edb.397.1663883416011; Thu, 22 Sep 2022 14:50:16 -0700 (PDT)
MIME-Version: 1.0
References: <LNXP123MB2569B8F0432A96CA9ED5F506887E9@LNXP123MB2569.GBRP123.PROD.OUTLOOK.COM> <1375C9A8-6ADD-4168-B0F7-5AF718C1EA06@painless-security.com>
In-Reply-To: <1375C9A8-6ADD-4168-B0F7-5AF718C1EA06@painless-security.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Thu, 22 Sep 2022 14:50:04 -0700
Message-ID: <CAOW+2dsGe45VByajY85tv6-iZScYcQuoFXEL5_xg3b0r2ApVTg@mail.gmail.com>
To: radext@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f586cf05e94b0bbb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/tAfcMEqew_AdsbPlC363xeDe7j0>
Subject: Re: [radext] BoF request for IETF 115
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, 22 Sep 2022 21:51:03 -0000

Just today, the CyberSecurity & Infrastructure Security Agency (CISA)
issued an Alert relating to threats to operational technology:
https://www.cisa.gov/uscert/ncas/alerts/aa22-265a

A question: Will the revision to RFC 6421 cover post-quantum
considerations?

On Thu, Sep 22, 2022 at 12:44 PM Margaret Cullen <
margaret@painless-security.com> wrote:

> I support holding this BOF at IETF 115, and I agree that work in this area
> is important for the continued success of RADIUS.
>
> Margaret
>
>
> *From:* radext <radext-bounces@ietf.org> on behalf of Alan DeKok <
> aland@deployingradius.com>
> *Sent:* Tuesday, 6 September 2022, 21:30
> *To:* radext@ietf.org <radext@ietf.org>
> *Subject:* [radext] BoF request for IETF 115
>
>   I've submitted a BoF request to recharter RADEXT for IETF 115.  The
> request is at:
> https://datatracker.ietf.org/doc/bofreq-dekok-bofreq-dekok-radius-extensions-and-security-00/
>
>   It includes a proposed charter.
>
>   Depending on the opinion of the IESG, the request might be rejected, we
> might have a BoF, or RADEXT might just be rechartered as WG.
>
>   The preliminary charter has been shared with the ADs.  It would be good
> to hear if other people have opinions on (a) the proposal to restart
> RADEXT, or (b) the charter and work items.
>
>   The high-level summary was to why we need RADEXT is included here, too.
> The link above has more information.
>
> ---
> There is increasing conflict between the security practices defined in
> RADIUS and modern cryptographic requirements. The move to RADIUS over TLS /
> DTLS has helped to secure the base protocol. However, the use of MD4 / MD5
> is still "baked into" RADIUS. The use of these digest algorithms makes it
> impossible to use RADIUS in a FIPS-140 compliant system.
>
> The WG will define a new SRADIUS which drops all use of MD4 / MD5, and
> will be suitable for use in a FIPS environment. This work is expected to
> require only minor changes to existing implementations.
>
> As part of this effort, the IETF will formally deprecate the use of RADIUS
> over UDP. There are still many cloud providers sending bare RADIUS packets
> over the Internet. This practice is insecure, and should be forbidden.
>
> RADIUS over TLS / DTLS are in wide-spread use. They should be updated to
> use TLS 1.3, to require Server Name Indication (which helps with sites
> hosting multiple authoritative servers), and to move the documents to
> standards track.
>
> In order to address the 8-bit ID limitation, we also propose to allow for
> more than 256 packets "in flight" on one connection between client and
> server. This change will permit higher throughput connections. Some vendors
> have already implemented their own versions of this work, which has proven
> to be successful in practice. This behavior should be documented and
> standardized.
> ---
>
>   Alan DeKok.
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>