3

I'm currently working on a protocol which passes automated instructions between separate organisations. I'm looking for a way to delegate authentication of devices to which ever organisation a device belongs to. This doesn't affect authorisation models, only authentication.

So to put this in terms of DNS domains:

  • organisation foomy.tld should be able to authenticate (eg: sign the certificate for?) new_deive.foomy.tld.
  • organisation acme.tld could choose to trust foomy.tld:
    • It should then be able to trust new_device.foomy.tld is what it says it is on the authority of foomy.tld
    • BUT organisation acme.tld should NEVER trust foomy.tld to authenticate any device outside the domain of foomy.tld.

Considering using x509 and SSL

In the case of x509 CA certificates, the CA role is usually performed by a third party CA. But that isn't appropriate for this purpose:

  • The creation / destruction of device IDs (services) is too rapid to consider a traditional CA (too expensive, too slow).
  • This mechanism needs to authenticate clients and servers. Devices / services do not always have public IP addresses so CA solutions such as LetsEncrypt aren't an option.
  • Creating a dedicated CA for this single purpose is not cost effective and likely to damage adoption.

So this leads to the idea of an organisation acting as their own CA for this purpose. But as it turns out, x509 really doesn't support this well, because once you accept a CA as being trustworthy you cannot limit the scope of that trust enough. IE: You cannot trust it to only sign certificates for it's own domain.

Considering re-purposing single sign on mechanisms

The single sign-on mechanisms I've looked at appear to be built around the concept of authenticating users. Background automated services don't appear to be well supported.

Maybe I missed something here.

Question - Keeping it as narrow as possible.

Is there another approach allowing this type of cross organisation authentication which I can use for my problem ?

Improve this question
21
  • 2
    This is exactly the kind of question where I think parts of the community act too strict in interpreting the site scope - yes, the last sentence is literally a request for 3rd party resources, which is off-topic here, so it already got two downvotes by some site cops for this reason (and an anonymous downvote). But this can be easily fixed by a small edit (which I did now), so why downvote in the first place instead of telling the OP what they should change?
    – Doc Brown
    Mar 6, 2019 at 6:37
  • Thanks for the edit. The changed wording is fine with me.
    – Philip Couling
    Mar 6, 2019 at 8:00
  • 1
    You can obviously do this if you control the code which does the validation. Since you say you are "working on a protocol" it would seem that is a possibility - it's not like this needs to work in every random web browser.
    – Chris Stratton
    Mar 7, 2019 at 1:48
  • @ChrisStratton Yes, you are right that obscure SSL libraries don't need to be supported. I would however expect it to be simple enough to re-implement. That makes it dangerous to rely on a feature only available with one obscure library.
    – Philip Couling
    Mar 7, 2019 at 10:21
  • 1
    If by 'manually' you mean write an if statement that checks that the CA domain is the same as the domain of the subject of the certificate, yes. Unless you use some sort of code generation tooling, I guess. It makes sense for what you want to do to be a thing but I guess you have to figure out how much time and effort you want to put into avoiding writing a tiny bit of code.
    – JimmyJames
    Mar 8, 2019 at 22:37

1 Answer 1

Reset to default
2

X509 certificates may contain namecontraints (see https://knowledge.digicert.com/solution/SO4583.html for a brief summary of the fields). You might be able to use these.

Openssl documents these nameconstraints as well https://www.openssl.org/docs/man1.0.2/man5/x509v3_config.html, so it can probably handle them in certificates.

I found this blog by Vadims Podāns: https://www.sysadmins.lv/blog-en/x509-name-constraints-certificate-extension-all-you-should-know.aspx It claims that both Windows cryptoAPI and OpenSSL support name constrains. It gives a sample of how to configure Microsft certreq.exe. And it describes some scenarios where this may be useful.

On security.stackexchange there is a question about whether MacOS supports them: https://security.stackexchange.com/questions/95600/are-x-509-nameconstraints-on-certificates-supported-on-os-x And MacOS does not support name constraints.

Thomas Pornin on security.stackexchange describes why name constraints do not work in SSL. Your situation is not SSL tough, you might be able to enforce checking the name constraint not not falling back to the common name.

I haven't tried nameconstraints though.

Improve this answer
1
  • Interesting point. Name constraints are exactly the feature that were discouraged in the link I gave due to lack of support. Admittedly that link was from 2013. Support by openssl is useful but openssl is by no means ubiquitous.
    – Philip Couling
    Mar 6, 2019 at 23:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.