Participating in more than one roaming consortium

[khuhtanen]

It is therefore necessary to decide on the certificate to present during TLS session establishment. To make that decision, the availability of Trusted CA Indication in the client TLS message is important.

It can be considered an important result of the experiment in {{RFC6614}} that Trusted CA Indication is an important asset for inter-connectivity of multiple roaming consortia.

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.

[Janfred]

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.

[restena-sw]

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.

[Janfred]

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?

[restena-sw]

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.