Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(radsec): how to implement TLS connections to client routers correctly #5

Open
TheoTechnicguy opened this issue Jul 3, 2024 · 1 comment
Labels
question Further information is requested

Comments

@TheoTechnicguy
Copy link
Collaborator

TheoTechnicguy commented Jul 3, 2024

After having experimented with RadSec locally using two OCI instances, several observations and questions come to mind.

Observations

  1. Connections are mutually authenticated (so mTLS works perfectly) and implementation is even mandatory (2.3.2 point 2 IETF RFC 6614)
  2. 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.
  3. 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...

  1. 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.
  2. 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.
  3. Certificate lifetime: How long should the certificates be valid? Do we have multiple lifetimes?
  4. Certificate distribution: How do we distribute certificates ...
    1. ... to the techie community that want to use their own hardware?
    2. ... to the non-techie community that have no idea how RADIUS works (and don't want to)?
  5. 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.
  6. Certificate alteration: (How) do we allow changing the binding value (from 2.) e.g. for ISPs that alter domain names or IP addresses?
  7. 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!

@TheoTechnicguy TheoTechnicguy added the question Further information is requested label Jul 3, 2024
@TheoTechnicguy
Copy link
Collaborator Author

My thoughts on the questions above.

  1. 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).
  2. 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.
  3. 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.
  4. .
    1. Possibly distribute a certificate after registration on a web page?
    2. I think that it's enough to package everything as a kit.
  5. This will depend on the lifetime, but ideally something that we can easily automate.
  6. Those ISPs are annoying.
  7. If we manage to automate renewal, I would prefer for passive revocation (it's more commonly implemented and doesn't require an internet connection)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant