Open khuhtanen opened 1 year ago
At least Radsecproxy sends an indication of the allowed client CAs, you can see that by connecting to the server with openssl s_client
.
And as far as I read the text it does not make a distinction between client/server, so this applies to both.
This inverted way of signaling authorisation does not have a use case right now:
The client chooses to contact the server because it has an existing request in its queue. This request will be attributed by RADIUS client to a roaming consortium (e.g. because it came in on an SSID belonging to a specific consortium, or there is a Passpoint Roaming Consortium indication attribute, or...).
Because of that known consortium attribution, the client expects a specific consortium's server cert+CA - which makes it important that the client signals to the server which CA the client expects.
The client will thus know and choose its own specific client certificate for the expected roaming consortium prior to starting the RADIUS exchange - no need for signalling, and no point in re-negotiating.
I actually have a (admittedly very specific and unusual) use case right now where it would have helped with CA rollover. (If radsecproxy would support it) This would make it possible to switch trust anchors independently on both sides. Once the new certificate is configured on the client, the server can switch at any time to the new trust anchor and the client will then send the new certificate. Right now this is only possible by either allowing two trust anchors or synchronous config change.
The question is: Is there harm in also including the spec for the client side? Maybe modify this in SHOULD/RECOMMENDED for the client to include the trust indication in the ClientHello and MAY/OPTIONAL for the server to indicate allowed client cert CAs?
Not sure I get why this would be useful. So a client has two client certificates for the same consortium.
The server would usually accept certificates from the old and the new CA, so it doesn't matter which certificate is presented (your "two trust anchors" above)
Once the old cert expires, the client automatically switches to the then-only certificate for future communication.
The only corner case where signalling would be important is if the old CA is removed from the trust base server-side before the old client certificate expires (then the client would erroneously believe it can still use the old, and fail when presenting that).
TBH, such a situation would make sense only if something terrible has happened to the old CA and it is in need of being decommissioned immediately, without waiting for expiry of its certificates. But yes, such a situation is not impossible.
So, to get back to the original question: nothing bad can happen if MAY or OPTIONAL support for this feature is added. So, if there's some value, why not.
Should the server also inform the client, which CAs it supports for client auhentication? Do clients have multiple client certificates to choose from for connections?
Because the current RFC 6614 and the implementations do not yet support this, I am running a separate Radiator instances in different ports for OpenRoaming and eduroam inbound RadSec connections on our IdP service.