[radext] RADIUS/(D)TLS port usage (was: Review of draft-ietf-radext-radiusdtls)

Jan-Frederik Rieckers <rieckers@dfn.de> Tue, 09 April 2024 10:17 UTC

Return-Path: <rieckers@dfn.de>
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 861F8C14F6A8 for <radext@ietfa.amsl.com>; Tue, 9 Apr 2024 03:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=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=dfn.de
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 Fz_KmE5eQmzo for <radext@ietfa.amsl.com>; Tue, 9 Apr 2024 03:17:13 -0700 (PDT)
Received: from a1004.mx.srv.dfn.de (a1004.mx.srv.dfn.de [194.95.233.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 1AA85C14F69E for <radext@ietf.org>; Tue, 9 Apr 2024 03:17:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dfn.de; h= content-type:content-type:in-reply-to:subject:subject :organization:from:from:references:content-language:user-agent :mime-version:date:date:message-id:received; s=s1; t=1712657827; x=1714472228; bh=wkBC7y6CpEqJg6tVb939Ws3SM6UuRIEYLzyIUWvtGig=; b= Wg/4yE0XHdvFbsUVC+Hyfl5dCB9zZqqXzehIbuIb7e/hjmuT3B/rdXkpKB3T8mrg tYaxMXfCCW15LXT6hhysVh38y7NUdtFUG1s/31f+p6GDCL82DO6X+fEcun5CGmdS eENOOFbXhXee0pohTzneAhvqaPm+3mgYJi+zoICaq6A=
Received: from mail.dfn.de (mail.dfn.de [IPv6:2001:638:d:c102::150]) by a1004.mx.srv.dfn.de (Postfix) with ESMTPS id 939B92000DD for <radext@ietf.org>; Tue, 9 Apr 2024 12:17:07 +0200 (CEST)
Received: from [IPV6:2001:638:d:1016::1003] (unknown [IPv6:2001:638:d:1016::1003]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mspool2.in.dfn.de (Postfix) with ESMTPSA id 11E0A31 for <radext@ietf.org>; Tue, 9 Apr 2024 12:17:06 +0200 (CEST)
Message-ID: <2e70196c-0def-401f-83ed-0eb924cc60eb@dfn.de>
Date: Tue, 09 Apr 2024 12:17:05 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: radext@ietf.org
References: <CA9BEA9C-39EF-4764-A0FE-D122413B37F7@deployingradius.com> <18ef8267-474e-49ae-9204-0c6c79d5e50c@dfn.de>
From: Jan-Frederik Rieckers <rieckers@dfn.de>
Autocrypt: addr=rieckers@dfn.de; keydata= xjMEYS90/RYJKwYBBAHaRw8BAQdAWXYFYTJZD1YR1SztUNqHenPGnf+gdQe/9LjiHlr2XATN J0phbi1GcmVkZXJpayBSaWVja2VycyA8cmllY2tlcnNAZGZuLmRlPsKWBBMWCAA+AhsDBQsJ CAcCBhUKCQgLAgQWAgMBAh4BAheAFiEE/fv7DCp4WBOrb8RyDYuiXSS+ypYFAmVbGkYFCQWP mkkACgkQDYuiXSS+ypYT0AD/TZAi4LsaVAAzkFSuejWnhQKRyJiPKcZUo7RHhGe1DAABAOBV K+OUb4o43IP2fVcVxKL9kyxArIAhehHp4cplQl8PzjgEYS90/RIKKwYBBAGXVQEFAQEHQBxo 6esD49rxn4d3su5fJJL79XjfKNy26LiFE9Gpg38+AwEIB8J+BBgWCAAmAhsMFiEE/fv7DCp4 WBOrb8RyDYuiXSS+ypYFAmVbGlAFCQWPmlMACgkQDYuiXSS+ypadsAEAqZTaohfkaVGeSk5x iiOcy47K43+ze2dUm5qja0eUUuQA/RNoF//lH8NeFNxN0Qs/Ej7MOdbr9B//R7To8AtqgiMJ
X-Enigmail-Draft-Status: N11222
Organization: DFN e.V.
In-Reply-To: <18ef8267-474e-49ae-9204-0c6c79d5e50c@dfn.de>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms060902010509090106070700"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/TvqeNf3xHbzw2SW5v7PcTlf1ctQ>
Subject: [radext] RADIUS/(D)TLS port usage (was: Review of draft-ietf-radext-radiusdtls)
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: Tue, 09 Apr 2024 10:17:19 -0000

Hi to all,

I'm currently working on including the feedback from the session in 
Brisbane and other feedback on the list into the RADIUS/(D)TLS-bis draft.

I'll probably send a few mails, so we can have separate mail threads 
discussing the different issues.

This first is about RADIUS/(D)TLS port usage.

The current text in the draft contradicts itself:

On 20.03.24 03:55, Jan-Frederik Rieckers wrote:
>>    ... RADIUS/(D)TLS peers MUST NOT use the old RADIUS/UDP or 
>> RADIUS/TCP ports for RADIUS/DTLS or RADIUS/TLS.
>>
>>    This seems to contradict the first paragraph in 3.2?
> 
> I think this might be a result of different wording in 6614/7360. Would 
> have to check. I've added a TODO note.


In RFC7360 this text is in Section 3.2 (Server Behavior)

> Servers MUST NOT accept DTLS packets on the old RADIUS/UDP ports.
> Early versions of this specification permitted this behavior.  It is
> forbidden here, as it depended on behavior in DTLS that may change
> without notice.


RFC6613 (RADIUS/TCP), Section 2.2 (Assigned ports for RADIUS/TCP) has 
this to say:

> The "radsec" port (2083/tcp) SHOULD be used as the default port for
> RADIUS/TLS.  The "radius" port (1812/tcp) SHOULD NOT be used for
> RADIUS/TLS.


So basically, for DTLS using 1812/1813 is forbidden, for TLS it is 
discouraged.

My suggestion is to generally forbid using the RADIUS/UDP and RADIUS/TCP 
ports for RADIUS/(D)TLS, to make it absolutely clear that this is 
completely different.

With RADIUS/DTLS the argumentation is very clear, because this is not 
connection-based and it would clash if the same client also uses 
RADIUS/UDP without DTLS.

For RADIUS/TLS it would work to re-use the RADIUS/TCP port (RADIUS/TCP 
is probably not even implemented, only RADIUS/TLS), but to have it 
consistent, I would forbid it anyway.

Cheers,
Janfred

-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: rieckers@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822