Dan, There is a fundamental security property in all that we have been discussing: It MUST NOT be possible for an entity A, impersonating as entity B, to obtain any key material that entity B may actually possess at any time. And that, I fully agree with. However, you are going further and saying that that property can *only* be achieved by detecting the impersonation and hence, detection of impersonation by the key transport protocol is a MUST. And that, I disagree with. As I've tried to describe below, there is more than one way of achieving the same security property. Vidya > -----Original Message----- > From: Dan Harkins [mailto:dharkins@xxxxxxxxxx] > Sent: Wednesday, March 07, 2007 10:36 PM > To: Narayanan, Vidya > Cc: Dan Harkins; Sam Hartman; ietf@xxxxxxxx > Subject: RE: [Dan Harkins] comments on > draft-houseley-aaa-key-mgmt-07.txt > > > 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