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

Support Cryptosign trustroot/certificate #1568

Open
oberstet opened this issue May 15, 2022 · 3 comments
Open

Support Cryptosign trustroot/certificate #1568

oberstet opened this issue May 15, 2022 · 3 comments

Comments

@oberstet
Copy link
Contributor

# forward the client pubkey: this allows us to omit authid as
# the router can identify us with the pubkey already
'pubkey': _public_key,

# for authenticating the router, this challenge will need to be signed
# by the router and send back in AUTHENTICATE for client to verify.
# A string with a hex encoded 32 bytes random value.
'challenge': None,

# https://tools.ietf.org/html/rfc5929
'channel_binding': 'tls-unique'
'channel_id': ...

# a public key the router should provide a trustchain for its public key.
# the trustroot can eg be hard-coded in the client, or come from a command
# line option.
'trustroot': None,
'certificate': ...
@oberstet
Copy link
Contributor Author

oberstet commented May 15, 2022

rgd the goal of adding above trustroot feature - in Crossbar.io, there are 3 types of internal connections, that is connections between workers and nodes of Crossbar.io itself:

  1. management links: https://github.com/crossbario/crossbar/blob/09eaf37ce0dfc58e97ed8e0af428bea28dea61cc/crossbar/edge/node/management.py#L68
  2. proxy-router links: https://github.com/crossbario/crossbar/blob/09eaf37ce0dfc58e97ed8e0af428bea28dea61cc/crossbar/worker/proxy.py#L296
  3. router-to-router links: https://github.com/crossbario/crossbar/blob/09eaf37ce0dfc58e97ed8e0af428bea28dea61cc/crossbar/worker/rlink.py#L550

All of these connection types

  • use WAMP-cryptosign(-proxy) authentication, and
  • may or may not run over TLS, and
  • work for a given specific realm (a management realm for 1. in above, or an application realm for 2. and 3. in above), and
  • carry a single WAMP session - but may carry multiple WAMP sessions to a realm with the MUX-feature

Thus, all connection types are working single-realm-multiple-session (when MUXed).


Since all connection types work single-realm (either single or multiple sessions), it makes sense to bind the trustroot connections are authenticated against with that realm.

@oberstet
Copy link
Contributor Author

Case 1:

  • realm = federated
  • trustroots = different domains, associated via frealm

Case 2:

  • realm = plain
  • trustroots = same domain

That is:

  • always use WAMP-cryptosign
  • always require client-delegate-pubkey and router-delegate-pubkey certificates
  • always require client- and router-trustroots
  • if same trustroot, require plain realm and trustroot-delegate certificates
  • if different trustroots, require federated realm and associations with realm

@oberstet
Copy link
Contributor Author

oberstet commented May 23, 2022

One element to add is auto-generating node certificate files key.sig as part of node auto-discovery:

https://github.com/crossbario/crossbar/blob/09eaf37ce0dfc58e97ed8e0af428bea28dea61cc/crossbar/master/node/controller.py#L426

key.sig should contain the node authid, pubkey and address, and should be signed by the master node eth key.

The master node address should be included in key.pub as trustroot default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant