Three-way authentication/handing an authenticated client off to a different server?

Question

Hi,

I'm interested in creating a sort of hand-off authentication method, where there's a client and two servers (let's call them Alice, Bob and Carmen Sandiego, respectively). Alice is a client (in a browser) somewhere on the 'net, possibly behind a NAT that gives a different IP for outgoing requests to different addresses (I know there are some corporate NATs that do this, so just in case).

Alice logs onto Bob using standard challenge-response authentication. The goal is that Alice can now make a request to Carmen and be recognized as an authenticated user. I assume the best method would be to have Bob create some temporary passkey which is sent to both Alice and Carmen and Alice will send that passkey to Carmen. However, I'm no crypto expert and so I'm unsure exactly how to make this communication safe. That is, if there's an eavesdropper on the Alice-Bob line that accesses the passkey, it could just send this straight to Carmen and get unauthorized access.

So does anyone have any ideas about how to do this? I'm assuming it involves a lot of shared secrets, random numbers, and hashing, but I'm not sure exactly what's cryptographically sound.

Thanks, Robert

Answer 1

As long as the 3 machines only communicate over SSL with each other, you are safe. The weak point is going to be on the Alice browser itself. A person with access to the Alice browser might be able to extract the tokens and use them from another machine.

Answer 2

It sounds like you're talking about a key-exchange algorithm. This is a well-understood problem, you'll be glad to hear, although it's not particularly well understood to me, I must admit. The Diffie-Hellman algorithm seems to be the best example of this.

If you want to get a good understanding of this stuff, the standard text is Bruce Schnieier's Applied Cryptography. It's highly readable, as is Practical Cryptography.

Whatever you do, don't try and implement this stuff without thoroughly understanding the problem, or you'll just end up with a swiss-cheese security model. Always safer to use proven third-party products, although offhand I'm not familiar with any.

Answer 3

You might want to have a look at Kerberos. I don't know if this protocol satisfies your needs, but at least it is worth a try.

In particular with Kerberos a client can authenticat himself to a server1 that fore example can verify the clients password. If the client then wants to authenticate himself to a second server, he can ask for a ticket. A ticket is basically a short message that contains information such as the server ids, a timestamp and a session key K. This message is encrypted with a key that is shared by the two servers. The client receives the session key K and the ticket. With these two things he can now authenticate himself to the second server. I.e. the client sends the ticket to the second server, this server decrypts the ticket checks the ids timestamp etc. and gets the session key K. That is the client and the second server now share the key K, which they can use for the authentication.

I'm aware that this description is too short to include all details. I hope it is not too confusing.

Answer 4

Rather than passing authentication tokens, Carmen could use OpenID to authenticate Alice through Bob. This wouldn't involve Alice giving Carmen any credentials. It could involve another user interaction, but user-agent assistance (signed cookies or client certs) should reduce this (I generally have to interact with my OpenID provider the first time I authenticate for a consumer).

This assumes that Bob and Carmen can communicate each time authentication is needed.