-
Notifications
You must be signed in to change notification settings - Fork 98
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
REST API certificate based authentication #534
Comments
Hello @Gunni thanks for your suggestion, I'll add this to our product backlog for further investigation. The RIPE REST API currently only supports passwords and/or SSO credentials. This sounds like a good alternative. How likely is this to be adopted by users? There is some related discussion around authentication in the NWI-8 proposal on the DB-WG. |
Hello @Gunni, it appears that support for PGP keys was dropped from Client Certificate authentication in TLS 1.3. "The OpenPGP certificate type [RFC6091] MUST NOT be used with TLS 1.3." https://crypto.stackexchange.com/questions/63981/why-did-tls-1-3-prohibit-pgp-authentication Does it still make sense to consider this for Whois? |
Hey @eshryane, i did not mean PGP keys, i meant using x509 certificates. |
@Gunni Thanks for clarifying! Indeed we already support X509 key-certs, we will investigate this further. |
Has there been any luck with this @eshryane? x509 cert auth is very well defined and most clients I know of support it. And is infinately better than having to add a md5 password to the mntner. |
Hi @Gunni No update, but I haven't forgotten (we were discussing it last week in fact). There's a number of areas we'll need to investigate in order to implement this:
It's not a huge amount of work in total, but enough that it hasn't been a priority. I agree that it's long overdue to replace MD5 (not sure what the migration path will look like however, there probably won't be huge take-up of client certificate authentication). Now that you've reminded me, I will setup a test in our Release Candidate environment. |
@Gunni I've completed the httpd proxy configuration to forward a client certificate to the backend Whois server (if provided). We'll work on the necessary changes to Whois next, and deploy to RC in the next few weeks for testing. |
@Gunni We didn't have time to implement the necessary Whois changes before the 1.97 release, and we are waiting for a security review of our implementation, but I'm still planning to deploy this before the next RIPE meeting. |
@Gunni We didn't have time to add this feature to Whois 1.97.1, but we still plan to implement it. I will have an update for the DB-WG session at RIPE80 next week. |
@Gunni We've merged initial support for this feature. We will include the change in the Whois 1.97.2 release, but it will be turned off in production for now, until the community have tested it, and we also plan a security review. |
Has this been enabled for production yet or is it still for development only? |
Hi @daniel-brenot @Gunni We have implemented this feature, but we haven't enabled in production yet. We are planning to do a security review, and we are now also replacing our httpd proxy layer with F5, which we will depend on for SSL termination and forwarding the client certificate information. We hope to enable this soon. |
What about enabling it on test? Are we able to test it there? Do you have a link to docs for test db rest api? |
Hi @Gunni We plan to initially enable it in the Release Candidate environment, but we're going to wait until we switch the proxy layer from httpd to F5, hopefully we'll do this by the end of the year. Once the community have tried it out, and after it's passed a security review, we plan to enable it in production. |
Hi @Gunni I went ahead and enabled client certificate authentication in Release Candidate, so feel free to test: You'll need to generate a key-pair, then create a keycert object with the public key and add that to a maintainer. Then you should be able to connect over TLS with your key-pair, and authenticate a Whois update as the maintainer. Client certificate authentication should work on RC is still using httpd to proxy requests, but we are investigating client certificate support in F5 now. |
The whois code changes are in #637 |
I have verified that CREATE, UPDATE, DELETE objects works with client cert auth. Nice! However I still get Filtered objects back when READing, even if I am authenticated while querying.
Please ensure getting unfiltered objects works when requests are authenticated! Edit: Additionally, when doing updates like this, the update emails that normally say: |
Hi @Gunni Thanks for testing! Good to hear it's working for you. We haven't implemented client certificate authentication for reads yet (GET requests), only for updates (POST, PUT, DELETE). We will add this in the next release. |
Hi @Gunni this feature is still on our list, we had some problems making it optional with the F5 loadbalancer we're currently using. We plan now to move HTTPS support to the backend application and allow client certificate authentication there. |
Hey, it's been a year, are there any news? |
Hi @Gunni Happy New Year. Yes I presented on client certificate authentication at RIPE87 in Rome: We've implemented Client Certificate authentication together with backend HTTPS in the Whois 1.109 release. Unfortunately there is a blocking issue that's preventing us from enabling it just yet: the client certificate request in the TLS handshake causes browsers to ask the user to choose a certificate, which annoys users who don't want to use this feature. This happens not only when clicking on Whois REST API links but also for requests within single page web applications. We're going to avoid this issue by creating a separate fully-qualified domain name just for client certificate authentication, and deploy in the next Whois release. Apologies for the delay. |
Hi @Gunni I've documented how to use Client Certificate Authentication in the DB documentation with an example: Use the host name |
I'm closing the issue as client certificate authentication is now implemented and deployed in Whois. |
Reopening issue as @Gunni reported: "But it still does not provide unfiltered fields for authenticated requests, which is what I need for to implement idempotency in clients that maintain records, I cannot see what auth sso are on a mntner so i would need to post the object every time to ensure it is as it should be." Apologies I've confirmed this is not working, we'll fix in the next Whois release. |
Hi @Gunni I am pleased to inform you that Client Certificate Authentication for lookups is now supported. With this update, you can retrieve unfiltered information for your objects using your certificate. This feature is included in the 1.113 release. Could you please confirm if this resolves the issue you were experiencing? |
It partially works!I made my key-cert using this (RSA is so 1977) Then used this query: What works is that i get the auth: sso emails, fantastic! However, other fields are missing/filtered, such as In addition to that, the last tag still says Filtered {
"name" : "source",
"value" : "RIPE",
"comment" : "Filtered"
} It should not be filtered at all if I am authenticated for that object, so I'll give partially done. Think of it this way, I should be able to generate an object on my side and diff every field, including those above, and remarks, and if not correct, I'd submit a PUT for it. NotesThings that I noticed while testing this Documentation issueNoticed while making my key, documentation of key-cert is outdated. Only specifies PGP keys. While online documentation is fine.
Also the format of the Email notificationThe email notification i get when someone updates a record that I watch using p.s. Short OpenPGP key IDs are insecure. |
Hi @Gunni thanks for your feedback! REST API lookups are filtered by default, even if you're authenticated. You need to add the Thanks for pointing out the documentation issue, we will fix it. I agree that short key-ids are insecure, but we are using it as a primary key, not for authentication, and it must be unique. I think using the full key fingerprint as the primary key would be unwieldy. We are open to feedback to change this though (just how we currently do it). We do plan to deprecate MD5 hashes as announced at RIPE88, client certificate authentication is a good alternative, and this will be announced as part of the impact analysis. Thanks again for testing our implementation. |
Since mntner objects can be locked using key-cert objects, and Client Certificate authentication is a thing.
I hereby propose its addition to the RIPE REST API.
In addition to being able to create, update, and delete objects when authenticated you could also allow requesting the full/unfiltered/unmodified object owned by the authenticated mntner.
The text was updated successfully, but these errors were encountered: