Re: [radext] Server identity in RADIUS/(D)TLS-bis

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

Hi all,

-- begin "moderator talk --

we've had a lot of things being said and I fear at some point maybe some 
misunderstandings too.

My head is spinning a bit and I'm trying to understand everything that 
was said and what that means for the specification.

I think we have different ideas of the term "identity" in different 
contexts and have different contexts that we base this idea on (as we 
all have a different view of the RADIUS world).


Coming back to the original question that started this sub-thread, and 
with that maybe resolving the thread and getting a bit of clarity for 
everyone:

The current draft says in the section about detecting live servers (3.3) 
this:
> If a RADIUS/(D)TLS client has multiple connection to a server, it MUST NOT decide to mark the whole server as DOWN until all connections to it have been marked DOWN.

So this is the origin of this discussion. We need to have a common 
understanding of what "multiple connections to a server" or "whole 
server" means in this context.


-- end "moderator" talk, begin my own opinion --

The text that I drafted in the pull request had primarily one specific 
use case in mind: A client or proxy opens a second (or third/fourth/...) 
connections to the same server because it ran out of ID space and now 
has two open connections.

 From my understanding, if my software opens a new connection to the 
same peer, but with a different certificate/SAN/.... or -- looking at it 
from another perspective -- if a peer with a different IP address 
presented the same certificate, those connections should be considered 
as connections to a different server, because they may have different 
policies attached to them, may be in different load balancing groups, 
may be two different instances in the same load balancing groups, ...

We don't need to go into detail about Routes or Identity of the RADIUS 
server (server meaning here: the actual final destination of the RADIUS 
communication, ignoring proxies), because that is probably irrelevant 
for this specification. What we want is to identify the same peer for 
lifeness checks, and we don't care whether it is a proxy or the 
authoritative RADIUS server.

As Alan said, RFC2865 doesn't define fallback (=redundancy or 
load-balancing) algorithms. So with the current specification a server 
being marked "DOWN" has zero (normatively specified) effect, as well as 
if the watchdog algorithm identifies a connection as down.
It's up to the implementation what to do with that information.

I don't think this document would be the right place to specify RADIUS 
redundancy/load balancing. That would delay this document even further 
and at least I would be happy if we could finish the document soon.


Cheers,
Janfred


On 12.04.24 16:39, Alan DeKok wrote:
>    So summarize my thoughts a little more clearly;
> 
> RFC 7585 clients SHOULD use SNI.  This information can be used by a server which handles multiple realms, in order to present a matching certificate for that realm.
> 
> Other TLS clients MAY use SNI.  The SNI realm SHOULD be configured by the administrator of the RADIUS client.  The SNI realm does not need to be the same as any realm in packets sent by the client.
> 
> TLS connections MUST operate application-layer watchdog checks as per RFC 3559 Section 3.4.  TLS connections SHOULD also enforce idle timeouts, lifetimes, etc.
> 
> TLS connection liveliness checks MUST be applied on a per-connection basis.  There may be other connections to the same destination which are up and active.
> 
> Other issues of load-balancing, multiple connections to the same destination, etc. are outside of the scope of this document.
> 
>    Alan DeKok.
> 

-- 
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 | Jochem Pattloch
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822