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

[Alan DeKok <[e-mail]>]

On Apr 14, 2024, at 5:20 PM, Jan-Frederik Rieckers <[e-mail]> wrote:
> My head is spinning a bit and I'm trying to understand everything that was said and what that means for the specification.

  Less is more. 

  After going around a bit, I think we're best off avoiding the issue of identity.  RFC 7585 says how to connect to a server dynamically.  Every other kind of connection is configured manually by an administrator.

  The TLSbis document should discuss how to verify certificates for the TLS session, and leave pretty much everything else unsaid.  This is the RADIUS tradition.

> 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.

  Either RFC 7585 destination, or whatever the administrator configured as "the same server".

> From my understanding, if my software opens a new connection to the same peer, but with a different certificate/SAN/

  How can the "same" peer present a different certificate?

  I see it as:

a) RFC 7585 says "connect to example.com", and the server presents an "example.com" certificate which matches the checks in RFC 7585.  It doesn't matter if the certificate is different from one used by another RFC 7585 connection.  DNS points to it, and the checks pass.  It's the "same" certificate.

  Consider also moving servers.  If you have a connection open, and the domain updates DNS to a new server, then the new server should be considered to be the same one.  If the client does not treat both old/new connections as being to the same server, then the domain can never update DNS or certificates!

b) connection pools (IPs, ports, etc) as manually configured by an administrator.  The only difference between this situation and RFC 7585 is where the "connection to example.com" configuration comes from.  The rest of the analysis is the same.

> .... 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, ...

  If RFC 7585 or the admin says "these two connections belong to example.com", then they both belong to example.com.  I don't see why (or how) the client would treat different connections as being to different destinations.

  i.e. if the admin says "server A and server B are both authoritative for example.com", then it makes no sense for the admin to also put different policies on those servers.  That seems like a pretty major misconfiguration to me.

> 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.

  I disagree.  Each connection is independent.  We don't need to identity the same peer, ever!

  A client has a pool of connections to a destination realm.  When all of the connections are down, then packets to that realm are not routable.

  To repeat my other message in part, I think the following rules are the simplest description of what to do:


1) 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.

2) 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.

3) TLS connections MUST operate application-layer watchdog checks as per RFC 3559 Section 3.4.  TLS connections SHOULD also enforce idle timeouts, lifetimes, etc.

4) Any 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.

5) When all connections to a destination realm or server are down, packets to that destination cannot be forward, and should be discarded.

6) Other issues of load-balancing, multiple connections to the same destination, etc. are outside of the scope of this document.


  I think the only new thing here is (5).  RFC 2865 describes proxying, but doesn't say what to do when a home server is down.  I believe every RADIUS server does this already, but it's good to have that stated in a document.


  Alan DeKok.