3 ms·

It seems the answer could be to use HMAC. Perhaps, others could expand on this?

kmowery 12y ago
I'd agree. An HMAC allows A and B to send messages to each other, through C, without C being able to change or modify the message in flight. A and B just need to share the HMAC key. Handling (and changing) this key can be tricky; if an attacker acquires it, the entire scheme falls over.
- mangeletti 12y ago
  Thanks. Is there a specific reason why handling the key is tricky? Or, is this just a matter of keeping it secret?
  - kmowery 12y ago
    Yeah, it definitely needs to be kept secret. Since you specified that A and B can have a set-up phase before C is around, the initial setup is fairly straightforward. Depending on what the system is used for, how valuable breaking into it would be, and how long you expect it to be up, you might need to rotate the key every so often, by having A and B agree on a new key. This is a little more complicated; since B now needs to check C's HMACs against two keys (the original and the new one) until every message signed by the original key has expired.
    - mangeletti 12y ago
      Ah, I see - thanks for this clarification. Alpha server and Beta server can actually communicate after the initial setup, but I didn't want this to be a consideration in my scenario, since I don't want any such communication to be required during each permission message transaction (once per hour or day, etc. would of course be fine). Perhaps, I will provide an API method for automatically expiring an HMAC and fetching a new one. During this rollover period, messages sent using the old HMAC will be allowed to fail, since they can just come get a new copy from Alpha server.
anfedorov 12y ago
You certainly could. If you want to add something more complicated like an expiration time to prevent replay attacks, it might be a good use case for JSON Web Tokens: http://jwt.io/ http://jwt.io/
- captn3m0 12y ago
  I've always wanted to try JWT. This seems like a nice usecase.
zamalek 12y ago
+1 Another option is to not do any wheel re-inventing at all. Have C go to A and ask it for an TLS client certificate. C can just open a good old TLS connection to B with the certificate (mutual authentication). The shared "secret" (not really a secret) would simply be A's certificate thumbprint. Furthermore, certificates have tons of features built right in: including the expiry date that you are looking for.

I'd agree. An HMAC allows A and B to send messages to each other, through C, without C being able to change or modify the message in flight. A and B just need to share the HMAC key. Handling (and changing) this key can be tricky; if an attacker acquires it, the entire scheme falls over.

mangeletti 12y ago
Thanks. Is there a specific reason why handling the key is tricky? Or, is this just a matter of keeping it secret?
- kmowery 12y ago
  Yeah, it definitely needs to be kept secret. Since you specified that A and B can have a set-up phase before C is around, the initial setup is fairly straightforward. Depending on what the system is used for, how valuable breaking into it would be, and how long you expect it to be up, you might need to rotate the key every so often, by having A and B agree on a new key. This is a little more complicated; since B now needs to check C's HMACs against two keys (the original and the new one) until every message signed by the original key has expired.
  - mangeletti 12y ago
    Ah, I see - thanks for this clarification. Alpha server and Beta server can actually communicate after the initial setup, but I didn't want this to be a consideration in my scenario, since I don't want any such communication to be required during each permission message transaction (once per hour or day, etc. would of course be fine). Perhaps, I will provide an API method for automatically expiring an HMAC and fetching a new one. During this rollover period, messages sent using the old HMAC will be allowed to fail, since they can just come get a new copy from Alpha server.

anfedorov 12y ago

You certainly could. If you want to add something more complicated like an expiration time to prevent replay attacks, it might be a good use case for JSON Web Tokens: http://jwt.io/ http://jwt.io/

captn3m0 12y ago
I've always wanted to try JWT. This seems like a nice usecase.

zamalek 12y ago

+1 Another option is to not do any wheel re-inventing at all. Have C go to A and ask it for an TLS client certificate. C can just open a good old TLS connection to B with the certificate (mutual authentication). The shared "secret" (not really a secret) would simply be A's certificate thumbprint. Furthermore, certificates have tons of features built right in: including the expiry date that you are looking for.