Re: [radext] the future of RADEXT

I would be happy to see this WG alive.

On Wed, Feb 9, 2022 at 11:53 AM <lionel.morand@orange.com> wrote:

> I would be happy to contribute.
>
>
>
> Lionel
>
>
>
>
>
> Orange Restricted
>
> *De :* radext <radext-bounces@ietf.org> *De la part de* Bernard Aboba
> *Envoyé :* mardi 8 février 2022 21:18
> *À :* Alan DeKok <aland@deployingradius.com>
> *Cc :* radext@ietf.org; Benjamin Kaduk <kaduk@mit.edu>
> *Objet :* Re: [radext] the future of RADEXT
>
>
>
> 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
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>