Re: [radext] Nits and discussion items for draft-cullen-radextra-status-realm-01

Alan DeKok <> Thu, 23 November 2023 23:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 924A9C15C286 for <>; Thu, 23 Nov 2023 15:45:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r0_nDfHog2QS for <>; Thu, 23 Nov 2023 15:45:53 -0800 (PST)
Received: from ( []) (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 (Postfix) with ESMTPS id E4550C151081 for <>; Thu, 23 Nov 2023 15:45:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPSA id BF607561; Thu, 23 Nov 2023 23:45:48 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
From: Alan DeKok <>
In-Reply-To: <>
Date: Thu, 23 Nov 2023 18:45:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Jan-Frederik Rieckers <>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
Subject: Re: [radext] Nits and discussion items for draft-cullen-radextra-status-realm-01
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Nov 2023 23:45:57 -0000

On Nov 23, 2023, at 3:14 PM, Jan-Frederik Rieckers <> wrote:
> I would love for the Security Considerations section to address the security and privacy concerns of being able to detect the proxy path with server identifiers, routes, etc.
> This could be something like "if you don't want your server names out there, use non-resolvable alias names for them" or something like this.
> I can imagine that some administrators would not use this, because "how my local RADIUS server works is my trade secret", so adding a few paragraphs about the actual security and privacy concerns about this would help convince these administrators to activate it.

  Sure.  The mitigating factor is that the proxies are part of the proxy chain, and therefore trusted.  It's not clear why a proxy admin would be happy with proxying packets to other servers, but wouldn't want anyone to know that this is happening.

> Secondly, I think it would be useful if the Status-Realm-Request could have some other method of identifying the Requestor than just NAS-Identifier or NAS-IP(v6)-Address. Could we allow (and encourage) the "Operator-Name" Attribute in that too?

  Probably an Operator-Name is good enough.  "Company Foo proxied the packet, but you don't need to know where my RADIUS servers are located".

  I t would be good to have some kind of proxy identifier, even if it is opaque to everyone outside of the local organization.  That way other people can say "proxy ABCDEF is slow".  They don't know where it is, but the local admin knows which one it is.

> This way, proxy servers could block/rate-limit Status-Realm-Requests that originate from one specific operator, because their monitoring system has gone bananas (and i.e. tries to build markov-chains to build a list of all possible realms and if found bombards them with requests), but allow all other Status-Realm-Request, that don't originate from there.
> I don't think that NAS-Identifier or NAS-IP(v6)-Address can be used for that, esp. if NAS-IP(v6)-Address is a RFC1918 (or v6 equivalent) address or the NAS-Identifier has a very <sarcasm>unique</sarcasm> value like "wlan-controller".

  I agree.

> Additionally, this allows the RADIUS proxy to also account for policy configuration based on the Operator Name when answering the requests.
> I can imagine that, for example in the OpenRoaming world, some IdPs would deny access from specific SPs/ANPs that are found out to not comply with the federation policy, or there may be a case where a RADIUS Server only allows access to the IdP from two specific locations (i.e. guest access issued at one university is valid at both universities and three other research facilities in one town, but not outside of the town and that distinction is made based on the OperatorName attribute)
> Currently, the RADIUS Server would signal reachability, but all Access-Request packets would get denied (or in the worst case even discarded).

  I'll have to think about that.

  Alan DeKok.