On Wed, Apr 9, 2008 at 3:52 PM, David Schwartz <[EMAIL PROTECTED]> wrote: > > > Right, Gotcha! > > > > There is one flaw in this design however. > > > > Peers: > > A, B, E > > > > By this scenario all three peers would be able to communicate, not > > just A and B, but also E. > > Do you want the server to have to approve A to talk specifically to B? Or do > you just want A and B to be able to identify each other and make the > decision of whether or not to speak? > > The scheme, as I described it, will allow A, B, and E, to confirm who they > are speaking to. Someone with no identity will be rejected, and E cannot > impersonate A or B. > > Is the idea is that the server must specifically approve the A<->B link? In > other words, it's not enough for A to know that it's talking to B and vice > versa but each must specifically know that the server has approved its > communication with the other? > > In that case, the server should give either peer a signed object that > contains both parties' public keys. Whichever peer has that object can then > send it to the other. Each peer can validate the other peer's public key and > the object from the server, see a match to both its own key and the other > party's key, and approve the connection. > > This may be needlessly complex. If the server is actually in communication > with both A and B at the time, it can simply send each side the other side's > IP address, port, and the other side's public key. No need for any special > certificates or the like since there's already a secure channel to both > peers. In that case, each side simply confirms that the other side knows the > secret key corresponding to the public key the server gave it.
There's actually something else that can be done, and this is done by Kerberos and Active Directory Federation Services... You can have B contact the server and obtain a signed "authorization certificate" for its key that uses custom extensions to specify 'is authorized to connect to A' for a given timeframe, and have that be the certificate that B presents when connecting to A. Then, A looks for the 'authorized to connect to' list, finds itself in there, checks validity time, and makes the decision based on that. No need to share the public keys, nor is there a need to tell both sides about it if the signature can be verified. If you want the server to mediate access between peers without having to have your clients constantly connected to the server, that's a way to do it. -Kyle H ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
