Re: [radext] the future of RADEXT

Bernard Aboba <bernard.aboba@gmail.com> Tue, 08 February 2022 20:18 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 CFBD93A011F for <radext@ietfa.amsl.com>; Tue, 8 Feb 2022 12:18:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, 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=gmail.com
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 U5ncJjmmNKEB for <radext@ietfa.amsl.com>; Tue, 8 Feb 2022 12:18:42 -0800 (PST)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B14D3A1192 for <radext@ietf.org>; Tue, 8 Feb 2022 12:18:14 -0800 (PST)
Received: by mail-vs1-xe32.google.com with SMTP id j21so273539vsg.6 for <radext@ietf.org>; Tue, 08 Feb 2022 12:18:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8NTzvmN1OfXceg56+sHtZkoAP6VwBy4IbtHWRmYFU08=; b=QYuMeuLpt5eCwFivKWXLQ/6MfVvqwskIJdh5i37tA+BHQfCoAnljCSzh5Jfnvh8Bld uNpBINmMBiZHbAyDkd3REg9pWs7Hf392AlarNJYlfhzj2TV9aXgpwMXphoAzcIzAoL20 Zwa/EdYnWOeqFQTtg2BnlZXBNgh+jEW9aZbRvUwNQDephno0XlyEa1Z3EfDXxvRmapoN nmdaNPrC8qzKWOzdteGZ91e7G+jsjBKnHDbd0wbupFaftkv7hEQ6PRbgFQI1WXZGS5pf 7yLm+ayLPLa2War6wqHjkXtOR6sIYi7KeKF3T1I4TBn6mYCfMc3swOTWZbVQjoTanlb7 0XgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8NTzvmN1OfXceg56+sHtZkoAP6VwBy4IbtHWRmYFU08=; b=19AYvQOr4Ot71hTwQdQqEjU9uDQpGSkjVIi+8p+8jVyVUDRzNdHtzq9f7S8mZB518p 9P/bXaPjTO8+cG996uAgJhydYr01/S8rjsjB2nsXnHGfE5MdfKzmsQhfOVJPVo2TtxeB gXutM/vYNnOObTjMAMrYFUjtaZBNdcIiuymMCY4tGdidK1Qc/5sEBog9yzFtyU8m4+vy Q75/8D1cU+RfbYmgLEgggje6pCIV+QTnI+XHZ1/sPSMUhmfzfBSHGNyyQ3xLP/AZL0eG 1DUoIKYRx1XZGchVHzjPBS0thggD0deRmbIZ9gnKKd3SkJSz/MsRc0vIepTEq8bctbXy tNBw==
X-Gm-Message-State: AOAM531hXwuyvAgMvmvIk0j/Mw6BTprteykUTM1y1qEBAVCSQVUU4DoD bd9P782QWCN500QY0X3ilb1APD/G9oiR+cV1OO4=
X-Google-Smtp-Source: ABdhPJziomziaDsz725TjCWVEC638zSQKta0YLNYN95HE6qnrBIx40rbbBUMRDjclyu1pASWLk79q7I5w7rPwCetFP4=
X-Received: by 2002:a05:6102:1626:: with SMTP id cu38mr2308627vsb.63.1644351491737; Tue, 08 Feb 2022 12:18:11 -0800 (PST)
MIME-Version: 1.0
References: <20220208185920.GK48552@kduck.mit.edu> <46636323-221D-4CBE-9E97-8425A82F2460@deployingradius.com>
In-Reply-To: <46636323-221D-4CBE-9E97-8425A82F2460@deployingradius.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Tue, 08 Feb 2022 12:18:01 -0800
Message-ID: <CAOW+2duwKw-hnF+rzD9-4dG0Bq989Y8BALmOfuTdEZZzQv-WFA@mail.gmail.com>
To: Alan DeKok <aland@deployingradius.com>
Cc: Benjamin Kaduk <kaduk@mit.edu>, radext@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008d0bd605d7876ab8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/8scI_gCUgUfclc_OnXdKzezhm6s>
Subject: Re: [radext] the future of RADEXT
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 08 Feb 2022 20:18:47 -0000

Alan said:

"It would be useful to standardize RFC 6613, 6614, and 7360.  Along with
updating them for TLS 1.3, and adding things like Server Name Indicator."

[BA] RFC 6421 laid out the process for developing a crypto-agile version of
RADIUS.  The last phase of that roadmap (selection of standardization
candidates) remains outstanding, and needs to be completed.

"I suspect, however, that there is limited interest, even though such work
would be useful."

[BA] A secure version of RADIUS will not be easy to deploy, but it's an
important task nevertheless. The information that flows unprotected over
networks via RADIUS includes information on the control and management of
network devices as well as information that can be used to determine the
location of users.  From a cryptographic standpoint, the RADIUS protocol
was substandard in the 1990s, and now, 30 years later it represents a major
weakness in critical infrastructure.  That's the kind of problem that
governments may want to take an interest in fixing.








On Tue, Feb 8, 2022 at 11:26 AM Alan DeKok <aland@deployingradius.com>
wrote:

> On Feb 8, 2022, at 1:59 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > As such, I believe that we should close the RADEXT WG and continue to
> > redirect further RADIUS work to OPSAWG, including solutions for the
> > Identifier problem if energy appears to work on them.
>
>   I think that's reasonable.
>
> > Please let me know (on list is fine) if you have concerns about this plan
> > by 22 February 2022, along with any alternative proposals that might
> > address those concerns.  However, in order to demonstrate that there is
> > energy to keep the WG open and make progress on our remaining chartered
> > item, I would need to see interest from multiple individuals in pursuing
> > such a course of action, along with an estimate for when such work would
> > ultimately be completed (that would function as a deadline for
> re-assessing
> > the WG's progress and possibly closing the WG if insufficient progress is
> > being made).
>
>   I'm happy to work on RADIUS things.  It would be useful to standardize
> RFC 6613, 6614, and 7360.  Along with updating them for TLS 1.3, and adding
> things like Server Name Indicator.
>
>   I suspect, however, that there is limited interest, even though such
> work would be useful.
>
> > This is by no means a failure outcome; the WG has produced a lot of good
> > work and we should be proud of what we have accomplished even as we look
> > forward to what might be done in OPSAWG in the future.
>
>   I agree.
>
>   Alan DeKok.
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>