11–20 of 29 posts
I think Kerberos can be used in this kind of structure (with Kerberos tickets), but I should double-check that it doesn't require the ticket issuer to interact with the resource that's the subject of the tickets.
It seems the answer could be to use HMAC. Perhaps, others could expand on this?
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.
Gamma server takes this response+signature back to Beta server. Beta server verifies this and grants access. Depending on your design, you could have this signature sent on every request, or accept the message as confirmed and add it to beta server's knowledge (so next time gamma can authenticate much more easily via methods such as sessions or cookies or tokens).
ie, Beta issues a token to Gamma once Gamma presents proof. The token is internally linked in Beta's knowledge to a certain expiry date and Gamma's ID. For every next request, Gamma simply presents this token.
For a less abstract comparison, consider a VPN. Let's say I have OpenVPN running on a server somewhere (B). I keep the CA on another system (A). If I want to give my laptop (C) access to the VPN (B), all I need to do is generate a new certificate on C and sign it with the CA I keep on A. B will then accept the certificate with no direct message from A.
X.509 might be overkill for what you're trying to do, but the upside is that there is a lot of software for working with it, so you won't need to roll your own solution.
It seems the answer could be to use HMAC. Perhaps, others could expand on this?
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/
signature = sha256(gammaskey + starttime + endttime + privatekey);
request = { key: gammaskey, start: starttime, end: endtime, signature: signature };
The good thing here is that you don't need Alpha server anymore.
Earlier quoted context omitted.
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.
Thanks. Is there a specific reason why handling the key is tricky? Or, is this just a matter of keeping it secret?
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.
http://en.wikipedia.org/wiki/Security_Assertion_Markup_Langu...
shared_secret
AUTH_TOKEN=HASH(shared_secret + challenge_string)
Gamma -> Beta
"let me in"
Beta -> Gamma
challenge_string = "dlkjaflkjaflkjflkjflfkjflkj"
"give me AUTH_TOKEN and I will let you in"
Gamma -> Alpha
challenge_string = "dlkjaflkjaflkjflkjflfkjflkj"
"can you give me AUTH_TOKEN?"
Alpha -> Gamma
AUTH_TOKEN= HASH(shared_secret + "dlkjaflkjaflkjflkjflfkjflkj")
"here is AUTH_TOKEN"
Gamma -> Beta
"here is AUTH_TOKEN and challenge_string let me in"
Beta -> Gamma
if (AUTH_TOKEN == HASH(SHARED_SECRET+CHALLENGE_STRING)
"you can come in"
else
"no"