On Sun, Jun 11, 2006 at 02:57:02PM -0400, Charles Clancy wrote: > Thanks for your comments. This is quite obviously a -00 document. Many > of the inconsistencies you've pointed out are editorial, and certainly > not intentional. We redesigned large parts of the protocol a couple > times, and unfortunately there are artifacts of previous designs throughout.
For -00 version, this was in quite good state. I was able to implement a functional server and peer without any major problems and the number of places needing "liberal interpretations" of the text was very small. > We defined the format for "protected results indication" as out of > scope, mostly to get -00 out. If the WG wants to define it in the > draft, then that's fine with me. However, it might be useful to define > it in a seperate document, since like channel bindings, it could apply > to any method that supports a protected data exchange. As long as it is available at the same time as EAP-GPSK would be taken into use, I don't care that much whether it is included in the same document or not. However, I would like to avoid need for mandatory/optional selection and interoprability issues with some implementations implementing this or not. Making it mandatory for all cases (or not implement it at all, if that is preferred) would make implementations simpler. > We definitely need to add some specific text on what to do if MACs fail. > I imagine the server would send an EAP-Failure if it occured after > packet 2, and others would be silently dropped. One option would be to add a GPSK-ERROR opcode that would be used to information peer of the error. In case the keys have already been derived, this could be used as a protected result indication for the failure case. Peer would reply with GPSK-ERROR and server would finish the negotiation with EAP-Failure. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
