Re: [radext] BoF request for IETF 115

Karri Huhtanen <karri.huhtanen+ietf@gmail.com> Thu, 29 September 2022 06:52 UTC

Return-Path: <karri.huhtanen+ietf@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 AF95FC1526FB for <radext@ietfa.amsl.com>; Wed, 28 Sep 2022 23:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 cBxl9QGu34on for <radext@ietfa.amsl.com>; Wed, 28 Sep 2022 23:52:48 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 26BD7C1526F7 for <radext@ietf.org>; Wed, 28 Sep 2022 23:52:48 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id o2so821512lfc.10 for <radext@ietf.org>; Wed, 28 Sep 2022 23:52:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date; bh=vpatM45JPWT8hgy7SKXN+hKaHIBuAUH6BHoxSyB6v0I=; b=Aqv18jF6AX1rk9+GrAdCE5SHKhqifYy2rfiYtcMX0pu/uhL7FIm8GeIN40jIIpuTCI Fy+XXo/tq4OBgHiX9TAFjYDGy+Lc7Hr/8mlqCfxS9cm6GYEMWtd3XbMxn0A9oX44Gt9V Mg2E240ld63APetLYceZUEM9TOoScEu1sIL38VPjnei27Acdv1ycFTBPZyU67ZayXAca 2Po3DWY236Bco6kLn+IsfCynWv5JYn42FjHnKUpNsVJ4gV5zsP/NWNQd/HtckR+iB+Wm EyWCI90kXQa204Wv7jgOB2+UvwybrEMvw5u1mM7QRBCqhuixV4tYheAf8tiawUtwyG/R vegQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date; bh=vpatM45JPWT8hgy7SKXN+hKaHIBuAUH6BHoxSyB6v0I=; b=LXu6qgNaoyIwkqrH+p3s7jILEaGlBi/XkBeeoOsF8ZWKio4xs5Vos00ft9f6MeoMpK UW5P5nLSRiVRGVQGWk6WvH3UQZ5L4OnETuJNSxGSFMud5J+Y8r59KmNvvrc+45d19gPz 3c3NztC4jK1VjssBopHHSwc7jj9ysnyW0lH7bQwWKURwQFD4F6j+cvB5SUDC3iI8gP1p BQ/J95pXFY24aG3daOnL3mG0sP0N+kyMCzsQWoFFK0i+ZYVfufbby975iSc2zE6U6Joj UhCEkclGC7+J9W8SB0ztFtjANcYihHKtRGp+vzJnLasffUeYXWiqyjIBt4FU+FFYvDPk L/sA==
X-Gm-Message-State: ACrzQf3syWsH5MY1F+XfzQhp5JNZHaxZuJSOHkzVp25cx8IpRi1RlDrj Kcbp1RbT1irdsDe6038xXuk=
X-Google-Smtp-Source: AMsMyM7zQfNYpkM9gRk5NJf+euLzk+mUhxSOMDUJaby2556VhP3FywtZ2zOx9ndENL9EBgDtk3bsmA==
X-Received: by 2002:ac2:4bc5:0:b0:499:57e3:9cd2 with SMTP id o5-20020ac24bc5000000b0049957e39cd2mr792421lfq.351.1664434366169; Wed, 28 Sep 2022 23:52:46 -0700 (PDT)
Received: from [10.0.42.42] ([83.148.245.31]) by smtp.gmail.com with ESMTPSA id m8-20020a056512358800b004947f8b6266sm694654lfr.203.2022.09.28.23.52.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Sep 2022 23:52:44 -0700 (PDT)
Sender: Karri Huhtanen <karri.huhtanen@gmail.com>
Message-ID: <99daf815-c5e7-d8cb-b42e-8dc675bbf9d6@gmail.com>
Date: Thu, 29 Sep 2022 09:52:44 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.3.0
Content-Language: en-US
To: Alan DeKok <aland@deployingradius.com>, radext@ietf.org
References: <5D005CCD-AF06-488A-AE48-5738B35EA4A2@deployingradius.com>
From: Karri Huhtanen <karri.huhtanen+ietf@gmail.com>
In-Reply-To: <5D005CCD-AF06-488A-AE48-5738B35EA4A2@deployingradius.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/2dhGCu2dUkkZui-pMY8r8bAguUc>
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, 29 Sep 2022 06:52:48 -0000

On 6.9.2022 23.30, Alan DeKok wrote:
>    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.

I fully support this personally and behalf of Radiator Software. Getting 
things listed in Alan's Proposed Charter (the link above) standardised 
is important for RADIUS implementation interoperability and helps to 
solve issues we run to nowadays even more frequently.

> ---
> 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.

Although TLS-tunnelled EAP protocols provide some additional protection 
and privacy, that still leaves for example RADIUS accounting where a lot 
of private information including location information may be sent in 
plain text over Internet. Moving all RADIUS traffic inside TLS / DTLS 
and possibly mandating it makes sense.

br,

// kh