Three-way authentication / passing authenticated client to another server?
I'm interested in creating some sort of authentication method where there is a client and two servers (let's call them Alice, Bob and Carmen Sandigo respectively). Alice is a client (in a browser) somewhere on the network, perhaps behind NAT, that provides different IP addresses for outgoing requests to different addresses (I know there are some corporate NATs that do this, so just in case).
Alice logs into Bob using standard challenge-response authentication. The goal is that Alice can now contact Carmen and be recognized as an authenticated user. I guess the best way would be to create Bob a temporary passkey that is sent to both Alice and Carmen, and Alice will send this passkey to Carmen. However, I am not a cryptographer and therefore I am not sure how to make this communication secure. That is, if there is a listening device on the Alice-Bob line that is accessing the access key, he can simply send it directly to Carmen and gain unauthorized access.
Anyone have any ideas on how to do this? I guess it has a lot of shared secrets, random numbers, and hashing involved, but I'm not sure what exactly cryptographically sounds like.
Thanks Robert
source to share
You might want to take a look at Kerberos . I don't know if this protocol meets your needs, but it is at least worth a try.
In particular, with Kerberos, a client can authenticate to server1, which, for example, can verify the clients' password. If the client wants to authenticate to the second server, he can request a ticket. A ticket is basically a short message containing information such as server IDs, timestamp and session key K. This message is encrypted with a key that is shared by the two servers. The client receives a session key K and a ticket. With these two things, he can now authenticate to the second server. That is, the client sends the ticket to the second server, this server decrypts the ticket, checks the ID timestamp, etc. and gets the session key K. This is the client and the second server now uses the key K, which they can use for authentication.
I know this description is too short to include all the details. I hope this is not too confusing.
source to share
It sounds like you are talking about a key exchange algorithm. This is a well understood problem, you will be glad to hear it, although it is not particularly well understood for me, I must admit. The best example of this is the Diffie-Hellman algorithm .
If you want a good understanding of this, the standard text is Bruce Schneier Applied Cryptography . It is very readable like Practical Cryptography .
Whatever you do, do not try to implement this material without thoroughly understanding the problem, otherwise you will simply end up with a safety model for Swiss cheese. It's always safer to use trusted third-party products, although I'm not familiar with them.
source to share
Instead of passing in authentication tokens, Carmen can use OpenID to authenticate Alice through Bob. It will not be related to Alice giving Carmen any powers. This could be related to other user interaction, but user-agent help (signed cookies or client certificates) should reduce this (usually I have to interact with my OpenID provider on first authenticating to a consumer).
This assumes that Bob and Carmen can communicate every time authentication is required.
source to share