Lakshminath, Actually we're discussing my suggested additions to an individual submission that is in IESG evaluation stage. Since I do not believe they will be accepted at this point in time I don't see a point in elaborating on them here. We're intersecting on this issue for one reason and one reason only: HOKEY. If you want to a full description of the problem then read (and comment on) the "Problem Statement and Requirments on a 3-Party Key Distribution Protocol for Handover Keying." Please do so on the HOKEY list so we are sure to include all the people who might care but are not on this list. thanks, Dan. On Thu, March 8, 2007 12:41 am, Lakshminath Dondeti wrote: > Dan Harkins wrote: >> 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. > > Could you elaborate on what part is missing from my description please? > What is in the "state" that the parties need to agree on? > >> >> 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. > > In this round, I am trying to get a full description of the problem > before jumping into solutions, but now that you mention this what in > your view is wrong with this approach? What necessary properties are > lost? Perhaps exploring this might help us agree on the problem. > >> >> This is not the forum for this discussion. > > This is the IETF Discussion list after all and we are discussing an > individual submission that is in the IESG evaluation stage. To my > knowledge, this is the appropriate open forum. > >> 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. > > I am ok with an offline discussion in Prague, but I am not sure whether > we have that much time. > > regards, > Lakshminath > >> >> 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