Re: [radext] Server identity and RFC7585bis

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

On 11.04.24 15:15, Alan DeKok wrote:
> On Apr 10, 2024, at 3:56 PM, Michael Richardson <[e-mail]> wrote:
>> You need to give the certificate SAN dNSName for the server, or you can't
>> verify the certificate correctly.
>>
>> I think that "same IP addr and port" is a bad test for same server, as one
>> way to do multi-tenant would be to inspect the SNI and punt to different
>> backend servers.
> 
>    I tend to agree here.  The server identity is the certificate (or DNSName in the cert).  The IP/port are pretty much irrelevant.
> 
>    I've added some comments to this effect in https://github.com/radext-wg/draft-ietf-radext-radiusdtls-bis/pull/1
> 
>    Alan DeKok.

I completely disagree.

The purpose of defining a way to check if it is the same server is to 
make sure that we mark broken servers as down and don't use them in our 
load-balancing any more.

Nowhere does it say "A server certificate MUST NOT be used in more than 
one single server"
I would strongly object to putting it in, because there are use cases 
where you might use the same server certificate for multiple servers, 
i.e. because they are in a load-balancing or other form of redundancy 
setup, or because they have a common TLS termination point (i.e. a 
DPI-Firewall).

And just because the server presented the same certificate (with maybe 
multiple SANs) it doesn't mean that all connections to the server are 
the same.
If we go down the path with SNI, then I could have a connection that 
used eduroam-federation.example.com for one connection and 
openroaming-federation.example.com for another. The certificate may be 
valid for both DNS names, but the policy is different on the connections.

If we would say "Just compare the certificate" then the client would 
send OpenRoaming packets to the eduroam federation, or the other way 
round, depending on which connection was there first.


If we completely ignore the IP/port part, then a client would mark the 
whole redundancy cluster as down, just because they opened up a 
connection to one of them and they stopped answering.

And, the other way round, if there were other connection open to other 
members of the cluster, it would keep trying the broken server in the 
cluster, because there are still open connections to "this server", so 
the software can't mark the server as down.



We should make sure why we need to identify a client and a server.

 From my perspective, identifying a server has two reasons:
1. Make sure that redundancy mechanisms work (as described above)
2. Prevent opening unnecessarily many open connections to a server with 
dynamic discovery, just because the client is not sure if it's the same, 
while keeping deployment options open (i.e. different policies hidden 
behind different Server Names, but with the same certificate)


I'm not entirely sure, why we need to identify a specific client in the 
way the specification in RFC6614 was written
(i.e. "What is the problem we solve by having a way to identify a 
client" or more specifically "what are the consequences of identifying 
that two connections come from the same client")

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