[radext] Re: Final update to RADIUS/(D)TLS-bis

[Jan-Frederik Rieckers <[e-mail]>]

Hi Peter,

On 2026-09-22 11:54, Peter Deacon wrote:
> On Sun, 6 Sep 2026, Jan-Frederik Rieckers wrote:
> 
>> Hello,
>> I'm not sure if a "SHOULD" for the connection closure is sufficient.
> 
>> If a connection has a security issue it should always be closed 
>> immediately. Keeping the connection artificially open is harmful, 
>> because the client might start to send packets and those may even time 
>> out if the server knows the connection is unacceptable and does not 
>> process anything received on that connection.
> 
> If a client offends a server in some way a server should not be required 
> to provide immediate feedback if doing so would be harmful to the server.

This case is not "offend in some way", but a very specific case of 
"Certificate (or any other security-relevant property of the mutual 
authentication in the TLS handshake) was not valid, but it could not be 
verified before the "Finished" message of the handshake", so we need to 
do it after.

> A robust client implementation could issue an application keepalive 
> immediate upon session establishment or initially concurrently connect 
> to multiple servers using the one that responds first.  I don't support 
> requiring instant feedback to an offensive client.

This is already in the spec with Status-Server.
If the client fears the server may close the connection, the client 
implementation is free to send a Status-Server request to the server 
first, and if it responds, the connection is healthy, and only then 
start sending payload packets.


> Unfortunately given current draft even over a "reliable" transport a 
> perfectly valid request over a perfectly valid connection is allowed to 
> be summarily ignored with not even a best effort expectation of any kind 
> of response.

It's no different than RADIUS/UDP with a shared secret. A RADIUS/UDP 
server will ignore these packets too, even though they come over a 
"perfectly valid" connection (i.e. correct source IP address, as this is 
the only "security" for RADIUS, apart from the shared secret).

Normally, the presumption would be that if the TLS connection is 
established, it is valid. Since the operational experience has shown 
that there are cases where you need to close the connection due to a 
failure in mutual authentication that only is available to the 
implementation after the TLS handshake, we explicitly add this part in 
our spec, so clients know what to expect.

And again, if clients want to be sure that a connection is viable, the 
first packet can be a Status-Server request.


> Clients therefore have to be able to handle these bizarre situations 
> where even reliable transports act for all intent and purposes as if 
> they were unreliable.  Not just initially but throughout the life of the 
> session.
The moment that the first valid response packet has been received (e.g. 
the response to the Status-Server request), the client can assume that 
the connection is viable.

Any further (automatic) connection closure is based on security issues 
on the connection (e.g. due to alignment issues which completely breaks 
the packet boundaries for the following packets) or a misbehaving client.



I'm sorry, but from your comments I cannot see in which cases it is 
valid for the server to artificially keep a connection open.
In any case, the server cannot answer to any other incoming requests, so 
closing the connection is essential for the client, so the client does 
not send any further packets (that will not get an answer).

Cheers,
Janfred

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

E-Mail: [e-mail] | Fon: [phone] | Fax: [phone]
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 | Alina Hain
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822