If you have a 3 party key distribution scheme and at the end of it the 3 parties do not share ALL THE SAME STATE yet believe the protocol has successfully completed then your key distribution scheme is flawed. Dan. On Wed, March 7, 2007 8:32 pm, Narayanan, Vidya wrote: >> >> Since there is no binding of identities it allows an >> authenticator to say "give me the key for authenticator FOO" >> even though it is actually authenticator BAR. For instance >> the NAS-Id is put into a RADIUS request to ask for a specific >> key and the key is sent back protected by the shared secret >> bound to the IP address of the authenticator. Since this >> network access credential is symmetric all security >> properties that it could've had are are lost-- the lying >> authenticator can impersonate the client to the real FOO >> authenticator, it can inject traffic into a connection >> between the peer and the FOO authenticator, it can inspect >> traffic on a connection between the peer and the FOO authenticator. >> > > None of this is feasible when the key distributed to BAR (impersonating > as FOO) is different from the key distributed to FOO (appearing as FOO). > In other words, a peer connects to BAR and thinks it is connected to > FOO. The server also thinks the peer is connected to FOO; a key (say, > K1) is derived (with freshness) and given to FOO aka BAR. But, at this > point, the real FOO DOES NOT have K1. When the peer tries to attach to > the real FOO, it may attempt to use K1, but, will fail. If another key > is requested for/by the real FOO, all the server has to ensure is that > K1 is *never* given (in fact, K1 should never have been cached and MUST > be forgotten after delivery); a *different* key (say, K2) must again be > derived (with freshness, again) and given. > > In other words, no two key retrievals from the server must result in the > same key being distributed, even if the entity requesting the key is > *seemingly* the same. This only means that every transported key MUST > have an element of freshness (say, at least a server nonce) that must be > communicated with end-to-end protection between the server and peer. > > Ensuring correctness of identities while allowing the same key to be > retrievable upon multiple fetches is only *one* way to achieve the > security properties you are trying to achieve. In fact, *never* allowing > the same key to be retrievable multiple times even by the same entity > will consistently achieve these security properties, irrespective of the > correctness of identities. > > Vidya > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf