Hi Lakshminath, That's not entirely correct. As I recently stated to your colleage if a 3 party key distribution scheme finishes and all 3 parties think it finished successfully but they do not agree on all state then the scheme is flawed. I see the path you're trying to go down-- add a server nonce, assume everything is now fine-- and I'm not going to follow you down there. This is not the forum for this discussion. Let's take this to the HOKEY list if you really want to continue. Better yet we can discuss it over a Budvar in Prague. Dan. On Wed, March 7, 2007 10:51 pm, Lakshminath Dondeti wrote: > > > Dan Harkins wrote: >> Sam, >> > >> But for things like HOKEY or 802.11r they want to have the AAA server >> create a key hierarchy rooted off the EMSK or the MSK, respectively, >> that >> contains keys for specific authenticators. These keys are going to be >> distributed using AAA (that seems to be the plan) and either proactively >> distributed-- "here have a key!"-- or distributed on demand-- "gimme a >> key!" The authenticator-specific key gets produced by mixing in some >> identity of the authenticator and that key is then sent under the >> protection of the security association between the AAA server and the >> authenticator. > > Dan, > > I snipped all the rest of the email so I can get a clarification from > you on this particular paragraph. The problem you describe here is that > the authenticator gets a key based on the claimed identity of the > authenticator. If the peer and the server do not have a way to verify > the identity of the authenticator it is a problem because the key that > the server sends to the authenticator is the same as long as the claimed > identity of the authenticator is the same. > > Do I understand correctly? > > thanks, > Lakshminath > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf