X509 certificates usage concern

[bertocco]

I have a concern regarding paragraph 3.2.2, where the usage described for X.509 certificates is not the general/formal one: an X.509 certificate is issued following authentication via login and password. Formally, X.509 certificates are issued by a Certification Authority after the identity (of person, organization, or server receiving the certificate) verification by a Registration Authority. This formal identity verification is one of the strengths of security management through X.509 certificates, while we are skipping it completely.

Perhaps we should write something to not overshadow completely the formal use of X509 certificates.

[mbtaylor]

The intention here was not to go into the theory of certificate-based authentication, only the mechanics of how the client can acquire a certificate from a service, given some proof (username + password) that the user is the same person to whom the certificate refers. But I'm happy to adjust the wording if it will improve understanding of what's going on. @pdowler, since CADC is as far as I know the only provider doing this, can you comment?

[pdowler]

This ended up being long because: A little history:

CADC/CANFAR implemented IVOA CDP-1.0 way back because we needed a mechanism for (i) users to delegate authentication power to a service/site and (ii) services in the site needed to obtain those credentials to act on the user's behalf. The prime example was user runs a async TAP query and directs to the output to a VOSpace location they can write to, but there are many more.

In addition to the CDP standard endpoint, the credential service also needed a private API so trusted services in the site could do (ii). I'm kind of against the concept of private API because people (us, developers and ops) start thinking that's only used by our code and security erodes pretty quickly... so we made that a public API as well: users could authenticate and download a short-lived proxy certificate (usually for use on automated processes like batch processing, but also for use with command-line clients so they would enter username/password once and then do a bunch of things).

In addition, despite IVOA SSO-1.0 recommending that client certificates was the way to do global SSO and CDP-1.0 existing (thnx former GWS!) and that it completely works... people didn't actually want to go and get a client certificate from a CA, understand public/private keys and certificate management and formats, etc (because honestly: the concepts are solid but the experience is terrible). So we also implemented our own internal CA so that users that didn't delegate (CDP) could still download a short-lived cert (signed by CADC) and use it with CADC/CANFAR services.

---

Fast forward to today: making actual proxy certificates work on the server side is quite painful. In late openssl-1.1x the option to enable proxy certificate support with an environment variable was removed from the library. Applications (apache, nginx, haproxy, etc) are supposed to offer a confirguation option and invoke an openssl function to enable proxy certificates. All of those communities (and others) have long-standing issues/requests for proxy certificate support be added, but it is considered niche usage and no one wants to do it. It's been years and at this point, real proxy certificates are dead...

But, our cred service still lives and works, but no longer implements CDP-1.0: just the custom endpoint to authenticate and download a user certificate, except now it is not a proxy certificate: it is a real, internal CA-signed client certificate (with a short lifetime). That endpoint is now more like a credential exchange API in that users can use one type of credential to obtain another.

So that's where we stand now. It's certainly a somewhat bespoke, but in my view client certificates still fill a useful purpose in a lot of automated work loads that require authentication (and where tokens are complex/painful).

Our cred service is open source and we publish a docker image that someone else could use (with suitable config)... the only real limitation (to what/where the certs can be used) is trusting the signing cert of the service (we use an intermediate CA signed by our internal root CA).

---

The real crux of this kind of client certificate usage is that we made it a public API instead of trying to hide it behind web pages... all the other things like this (eg MyCert back in the day) also had download a client cert feature as well :-)

Is it useful? yes
Is exchanging credentials for certificate a viable IVOA API? probably not
Can AuthVO describe it? sure, why not?
Should AuthVO describe it? does that sanction it in some fashion?

[bertocco]

I agree with this approach to using client certificates, because it effectively satisfies our use cases. I think it should also be described in AuthVO, but we should also mention that there is a more formal approach, and that if someone already has a certificate, it can be used. (The situation is similar with tokens, I think).
My goal is simply to ensure that, if someone raises concerns, we can point to a solid, well-documented rationale for our choices — clearly stating that our approach is deliberate, necessary, and justified within our context.

[pdowler]

Yes, it does need to be clear that if you have a certificate of your own you can use it to authenticate; you don't need to obtain one from the advertised source. That makes it different from cookies and tokens, for example.

[mbtaylor]

I didn't appreciate that fact about the CADC services - so is it the case that any certificate signed by a trusted CA will be accepted by CADC services? Is the list of trusted CAs supposed to be reasonably obvious (e.g. a superset of the ones that a current browser or python/java would trust) or is it going to be bespoke to the service?

My understanding when I wrote this part was that if a client didn't have a certificate issued by that particular service, it had to go to the access_url and get one; that's not quite explicit in the text but it's how it's implemented in my client code. But it sounds like that's not the case; if the client has any suitable certificate it may present it for authentication.

If I've got that right the question arises how the client knows for a given certificate that it may be in possession of, whether it's suitable for a given service. Is there a way that the ivoa_x509 challenge can/should (without undue complication) usefully communicate that? Once you've got a certificate using the information in any ivoa_x509 challenge can you use it to talk to all other services that issue an ivoa_x509 challenge? Since it seems that using certificates in this way is rather niche, it would probably be reasonable to define it in a way that matches CADC usage rather than trying to go for full generality of how other services might (but probably won't) want to use this route.

If I understand this point better I could try to come up with some text that would clarify what certificates are doing here, to address Sara's original point. Or somebody else could come up with a PR to address it. Given the focus of this document the main thing is to explain what clients (and services) have to do to establish authentication, but additional background can be added if it doesn't obscure such instructions.

[bertocco]

I agree with this statement by Mark: "Since it seems that using certificates in this way is rather niche, it would probably be reasonable to define it in a way that matches CADC usage rather than trying to go for full generality of how other services might (but probably won't) want to use this route.".
We should simply state that the CADC usage is the way we propose to use certificates within the IVOA, as it addresses our use cases and it avoids a certain level of complexity associated with the formal use of certificates. My point was not so much about insisting on the ability to use any kind of certificate, but rather about clearly explaining how and why we’re using them this way — to avoid criticism.

[mbtaylor]

@pdowler I seem to recall that you have some support for cookie-based authentication in your services. Is this likely to evolve in the forseeable future into an implementation of the ivoa_cookie auth scheme as described in this document?

If so, and in view of the fact that ivoa_x509 looks like it is in practice quite specific to CADC, then ivoa_x509 is not really needed (no services will exist for which ivoa_x509 is the only way for an AuthVO client to authenticate) and we could just eliminate ivoa_x509 altogether. Removing text from standards is always a win!

What do you think?

[pdowler]

Yes, our services will allow client cert authentication from any valid certificate, which means all the normal CAs bundled with the operating system plus a few extra CAs we have added. Currently the extras are GridCanada and Terena (which iirc is part of European Open Science grid/cloud infrastructure). I think the number of such non-standard CAs would be quite small (unlikely to be more than one science CA per country and there is probably a list of those somewhere.

Most of our CADC/CANFAR user can get a client certificate from us, but it is signed by an internal CA and thus only valid when connecting to our services. That's a hard distinction to draw in AuthVO...

In the headers from our services, we output several ivoa_x509 challenges:

www-authenticate: ivoa_x509 standard_id="ivo://ivoa.net/sso#BasicAA", access_url="https://ws.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/cred/generate"
...
www-authenticate: ivoa_x509

The first one (and others like it) that has extra info says we'll accept client cert issued by our cred service. The last one (with no info) is intended to convey that we'll accept any valid client cert the user might have.

It's obviously implied in both cases that valid means "signed by a trusted CA", but I don't think that list of CAs is a detail that can or should be conveyed.

So my 2c is that a plain www-authenticate: ivoa_x509 should be used to indicate that any valid cert from a legit CA is, in principle, usable.

[pdowler]

Yes, I have a plan to add a "cookie issuer" service so we can provide ivoa_cookie challenges in all our services.

One thing that is making me procrastinate is that we're looking at out-sourcing some of our AAI to CILogon (specifically, accounts and login) and it could be the case with that move, 2FA, etc that we won't be able to (or want to because of complexity) support username/password in a non-browser environment... once the browser side is using "Login with CILogon" then I think cookie auth might be limited to browser use (like it is now)

[mbtaylor]

I have drafted some text at #16 which matches the better understanding I now have of the intention here, and I hope addresses @bertocco's original comment. But please feed back if you feel that it still needs improvement.