Re: [radext] Proposed charter text based on IETF-115 BoF

[Matthew Newton <[e-mail]>]

On 24/11/2022 16:23, Jan-Frederik Rieckers wrote:
> On 24.11.22 16:14, Bernard Aboba wrote:
>> For backwards compatibility, servers probably need to support RADIUS 
>> and the existing RADIUS over (D)TLS anyway.  So really we're talking 
>> about an "SRADIUS" configuration flag.  If a site requires FIPS, why 
>> can't it flip the SRADIUS flag and run its SRADIUS server on port 
>> 2083?  If some devices can't connect to an SRADIUS-configured server, 
>> then those devices don't support SRADIUS and presumably the site wants 
>> to point them at another server (one without the SRADIUS flag set), 
>> and eventually replace them with devices that support SRADIUS.

> But without negotiation of "RADIUS or SRADIUS" we have a huge 
> compatibility issue.

> Of course you can do this locally if you have control over all involved 
> servers, but if you don't then this is not possible without a flag day 

I'm not sure why you would need a flag day? Or a configuration flag.

There is no need to update all servers at once, just each hop. The 
"upstream" server can be configured to listen on the new SRADIUS port as 
well as e.g. 1812/udp. Then the "downstream" servers can in time be 
configured to connect over SRADIUS instead of UDP. Once nothing is using 
1812/udp, the "upstream" server is reconfigured to stop listening on it.

Over that particular hop no message authenticator / shared secret / MD5 
is used, and there is a wider range of possible message IDs available. 
Over the other hops, the RADIUS packet is encoded as before.

> If people are worried about being FIPS compliant, they can choose to use 
> SRADIUS with the new port. The implementation overhead for SRADIUS (if 
> you already support RADIUS/TLS or RADIUS/DTLS) should be minimal, so 
> vendors should be able to implement it quickly and admins may switch to 
> SRADIUS at their discretion once their software supports it.

Sure. But no need for any flag day for e.g. an entire federation to 
switch over. And, with a new port, no need for any protocol level 
negotiation - this keeps things much simpler. Each hop-by-hop connection 
can be upgraded separately as required.

-- 
Matthew