You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After having experimented with RadSec locally using two OCI instances, several observations and questions come to mind.
Observations
Connections are mutually authenticated (so mTLS works perfectly) and implementation is even mandatory (2.3.2 point 2 IETF RFC 6614)
Passive revocation works both for sides (expired certificates are not accepted) - I haven't tried active revocation, but as it is advertised in the configuration files, I suppose it will work.
Certificate's CN (Common Name) and SAN (Subject Alt Name) attributes are ignored when verifying the remote party. Checks will have to be implemented with the verify stanza. The certificate chain does work.
Question
For the purposes of this project...
Managed or custom PKI: Should we use an existing or a custom PKI (Public Key Infrastructure)? Using an existing/managed PKI relieves us from safety and security concerns, as well as from having to manage it. On the other hand, using a custom PKI leaves us independent and more flexible compared to CA/B CAs. It could also be more secure when done correctly.
Certificate binding value: What value should we put in the CN or SAN so that we can bind the certificate to a remote party. We will also have to implement and validate this verification logic as per observation 3.
Certificate lifetime: How long should the certificates be valid? Do we have multiple lifetimes?
Certificate distribution: How do we distribute certificates ...
... to the techie community that want to use their own hardware?
... to the non-techie community that have no idea how RADIUS works (and don't want to)?
Certificate renewal: How do we manage renewing certificates for the same two categories of communities? I think this will depend a lot on question 3.
Certificate alteration: (How) do we allow changing the binding value (from 2.) e.g. for ISPs that alter domain names or IP addresses?
Revocation method: How do we revoke certificates? What is our tolerance / when do we revoke a certificate (what is the fair use policy)?
Thoughts and comments welcome!
The text was updated successfully, but these errors were encountered:
I would tent towards using a custom CA tree as we will not have to comply with CA regulation we (maybe) cannot (like opening port 80 for ACME).
The easiest value would be the public-facing IP address. The problem I see here is for IP changing ISPs. Using a domain name could be easier using dynamic DNS entries and updating scripts but requires more infrastructure.
I am somewhat biased here. I really like the idea of passive revocation, so the certificate's lifetime should be short, which also means we absolutely have to be able to automate renewal.
.
Possibly distribute a certificate after registration on a web page?
I think that it's enough to package everything as a kit.
This will depend on the lifetime, but ideally something that we can easily automate.
Those ISPs are annoying.
If we manage to automate renewal, I would prefer for passive revocation (it's more commonly implemented and doesn't require an internet connection)
After having experimented with RadSec locally using two OCI instances, several observations and questions come to mind.
Observations
verify
stanza. The certificate chain does work.Question
For the purposes of this project...
Thoughts and comments welcome!
The text was updated successfully, but these errors were encountered: