I have a fairly clear understanding of edge-client authentication with the controller. This ends up with an opaque session-token (which is a uuid). The client can use the session-token to retrieve a list of services it has access to. Each service would contain the list of edge-routers that allows access to it and the client can move forward and establish the connection with the closest edge-router
Could you please elaborate on how, subsequently, the router "authenticates" the edge-client when it attempts to dial or bind using the session-token?
Could the session-token be replayed by a 3rd-party if it were intercepted?
Hi @plakdawa,
That's a good question. I'm shocked I've never asked it (or forgotten the answer when I did). It probably needs @andrew.martinez to comment as he's really "the authoritative source" of answers for questions like this. My guess would be that these session tokens are scoped to the identity that authenticated. So even if you obtained the session token, you'd also need the key/cert that was used to auth to OpenZiti. I'll point Andrew at this post tomorrow and get a "final answer" soon.
Thank you so much @TheLumberjack .
The opaque session tokens are tied to the authentication mechanism used. If certificate authentication is used, the session is tied to that certificate and the authenticating certificate must be used in conjunction with the session token.
However, if other authentication mechanisms are used (usernames/passwords, external JWTs), overall security significantly decreases as there is no pre-existing certificate to tie a session token to.
1 Like
Thank you @andrew.martinez for this explanation.
As a follow up, with regards to using certificates as the first-factor, is there a difference here depending on whether we use service managed certificates or certificates from a 3rd-party CA i.e. is the session-token bound to the certificate in either case?