Comments and questions on the MCP from a Service point of view

[Robert Aarts]

Hei!

I'm pretty new to the maritime world (but experienced in identity management) and currently working on (concepts of) some services that could potentially benefit from the authentication and authorization offered by the MCP.
I'm reading https://docs.maritimeconnectivity.net/en/latest/MIR.html and now I wonder if I got this ;), especially with regards to the use of OpenConnect tokens.

As a Service I should make it clear that users of the Service should present OCID tokens that comply with the MCP, i.e. obtained from an MC Identity Broker and contain an mrn and an org (SHOULD or MUST the service care about any of the other attributes?). 

Now if the presented token is indeed deemed valid by the MCP Identity Broker, what can the Service (i.e the Relying Party) rely on?

That the user can indeed be assumed to be the holder of the identity stated in the mrn? Where is the specification that states that an MCP Identity Broker MUST do the check for certificate revocation? Or should the Service now do this? Where is it clear that the user authenticates using a PKI certificate at the Identity Provider? Who certifies the actual software used at the MCP Identity Broker and/or Registry?

I feel that the whole (very laudable!) effort of the MCP should be to make it easy to develop and deploy Services, so it would be great to have some documentation and guidance what is required from a Service and what it would get in terms of assurances.
For example I suspect (but haven't thought in detail about it) that it would be important to specify which Services an MCP Identity Broker will mint tokens for? Any Service (audience)? Or only those Services registered within the MCP? MUST the service also register with the MCP Service Register (that looks like a ridiculous large effort... but is a different story).

If I understood correctly, a Service could also choose to directly authenticate a user using the PKI certificate that the user should have. And then check for certificate revocation etc. This seems simpler,  and the trust model is easier to grasp, but requires agreement on how to actually do that authentication. Is the user cert to be used as client-cert in TLS? The doc says "connect with cert" which is a bit too vague ;), but the example using curl indicates that TLS client cert is used as the means to proof that the user has the cert and the associated private key, at least when authenticating at the Identity Registry.

Apologies for perhaps asking silly questions and thanks in advance for any clarification. And of course don't hesitate to ask me for more information!

With regards,

Robert Aarts

[oha...@gmail.com]

Hi Robert,

Thanks for the great questions!

I will in advance apologize that there might be parts of our online documentation that are not entirely up to date, it is currently on my todo list to get it up to date, but I am glad that it seems like you got a pretty good understanding of the MCP anyways. :) 

For the question of what guarantees an OIDC token gives, I guess the answer is, as with token based authentication in general, that the holder of the token knows the credentials to obtain the token, and that there is an identity that is registered in the MCP associated with the token. It does NOT give a strong guarantee that the holder is the actual identity, as we all know that username/password credentials can be broken or stolen. The possibility of authentication using a PKI certificate to get a token is only optional, but if the user chooses to do so, the MCP ID broker will make sure to validate the certificate and do revocation check before actually sending an OIDC token in return. In practice this is done using a mutual TLS handshake between the user who sends their MCP certificate and the nginx reverse proxy that is in front of the broker that sends its server certificate, and as part of this handshake both verification and revocation check of the user's certificate is done. After that nginx will forward the certificate to the broker which will then take the information from the certificate and put it into a token. The software that is used by the MCP providers that currently is in practice reference software that is developed by the MCP consortium (MCC) and it is also the MCC that certifies the different MCP providers. How the actual certification is done is not entirely clear yet, but formal documentations are currently being developed in the different MCC working groups. 

With regards to what requirements the MCP gives to service providers the answer is that in practice there are not any with the exception that if a service wants to use MCP based OIDC authentication the service needs to have an identity registered in the MCP to be able to get an OIDC client registered. This is only from the point of view of how the MCP works as the different MCP providers might have other requirements. With that said though we are trying to develop best practice guidelines for how service providers can and should use MCP. 

It is currently not a requirement that a service is registered in the service registry, but it is a recommendation in terms of it becoming discoverable by potential consumers. 

Yes, it is correctly understood that a service provider can choose to require users to authenticate using a MCP certificate and in my opinion this also gives a stronger guarantee of the identity of the user than OIDC based authentication. In practice this would be done using a mutual TLS handshake where the user presents their MCP certificate and the server presents its host certificate which in most cases would be issued by one the big TLS CAs (DigiCert, GlobalSign, etc.), but could of course also be done other ways if needed. Again, from the MCC's point of view we don't put any requirements on how to do this, but we are trying to make guidelines. 

I hope this answers at least some of your questions, and if there is anything that is still unclear you are of course welcome to point it out. :) 

And also if you haven't done so already I encourage you to take a look at our website https://maritimeconnectivity.net/ where we have links to our current public documents, and also instructions on how to get access to our public testbed where you can test the functionalities of the MCP. 

Finally we also encourage everybody who is interested in the MCP and wants to contribute to the development of it to join our consortium where we discuss the different aspects of the MCP in our different working groups. :) 

Best regards

Oliver

[Robert Aarts]

Hi,

Thanks for the explanations! I guess I'm getting most of this then :)

And yes in my experience a Service will almost always need a cert that is recognized by the TLS stack of the software used by the service user, as adding additional root certificates to that stack is usually a bit complicated. So the cert issued to a Service by a MIR will typically not serve the purpose of being usable as such for establishing a TLS connection. Therefor authentication of the Service to the user (software/TLS client) will have to be done in an additional step. For that authentication of the service to the user (software) I'm planning to look into SCRAM (https://tools.ietf.org/html/rfc5802).

FWIW an example service I am thinking about is a "remote piloting service", where something along a phone application would connect to vessel (NMEA) data over wifi and then connect to the service over the (mobile) internet. In this case the Service wants to be ensured that the vessel is the one it claims to be, and the Vessel wants to be sure that the Service can be trusted (and probably also that the actual pilot giving guidance is who she claims to be). I think this is a good use case for MCP as vessels from anywhere could appear and request piloting service, and likewise a vessel could approach any port, i.e. there is not always already-established trust.

As for contributing etc, I am happy to help out, and maybe can do that on a personal basis. I don't think it will be possible for my organization (Novia University of Applied Sciences) to join on a short notice, but maybe I can ask VTS Finland if I can be one of their "representatives". It was VTS Finland that pointed me to the MCP in the first place ;)

Thanks again, and more later....

Robert