> > 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