Hi Lakshminath, This version seems to address all my earlier comments. Thanks for working hard on the update!
(However, I haven't done a thorough review of -10/-11, which included quite significant changes that might have introduced some internal inconsistency.) One additional editorial nit for version -11: 17) Section 8, "The algorithm chosen by the peer for the MAC generation is indicated in the EAP-Finish/Re-auth message." Should this be "..in the EAP-Initiate/Re-auth message"? Best regards, Pasi > -----Original Message----- > From: ext Lakshminath Dondeti [mailto:[EMAIL PROTECTED] > Sent: 20 February, 2008 10:40 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: [email protected]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Gen-ART review of draft-ietf-hokey-erx-09 (-10) > > Hi Pasi, all > > Following up on this, I think ERX-11 addresses all of Pasi's > comments. > I have previously added (in v10) clarifying text to address the > lock-step issue based on Bernard's suggestion in his detailed > review. I > have now added a section on lower layer considerations. The channel > binding parameter processing is clarified in v11, primarily > in its own > section and also elsewhere. I have incorporated Pasi's > suggestions on > IANA considerations. Pasi's comment 3 is addressed by the > EMSK-hierarchy document. Anyway, I went over Pasi's list a > few times, > and think that all of them are now addressed :). > > Based on Dan's comments, I have added some more text to the security > considerations section (talked about implications of key compromise, > implications of hop-by-hop security and compromise of > proxies, etc.). I > have made the key naming changes in v10 already. > > I worked with Bernard's detailed comments in preparing v10; > additional > clarifications were added in v11 as well. > > I have also incorporated Joe's suggestions in v10 and v11. (Which > implies one of Alan's comments is not addressed. Joe wants less > repetition between the EMSK and the ERX specs and Alan wants some > duplication so the ERX document is more independent.) Joe's > suggestions > helped clean up the AAA related stuff and also the multitude > of options > in identifying the rIK used. The text is much more clear now > and there > is only one way to identify the key. Earlier options existed for > identity privacy reasons, but the working group consensus was that we > don't care about that requirement at the moment. It is simpler to > delete those now and add them in a future revision if > identify privacy > is deemed necessary then. > > Thanks again to all the reviewers. Thank you for your > patience while I > worked through all the comments and prepared the revised version(s). > > best regards, > Lakshminath > > On 2/19/2008 4:15 AM, [EMAIL PROTECTED] wrote: > > I have just scanned through version -10 of this draft, posted > > couple of hours ago. > > > > This version addresses my comments 5 and 6; and comments 4 and 10 > > are obsolete since the text I commented has been removed. The > > remaining comments are still valid. > > > > One additional comment for version -10: > > > > 16) Section 5.3.2, "EMSKname is in the username part of the NAI and > > is encoded in hexadecimal values. The EMSKname is 64-bits > in length > > and so the username portion takes up 128 octets." EMSKname is not > > defined in this document (or any of its references, as far as I > > can tell); and encoding 64 bits as hexadecimal doesn't take > > 128 octets anyway. > > > > Best regards, > > Pasi <snip> _______________________________________________ Gen-art mailing list [email protected] http://www.ietf.org/mailman/listinfo/gen-art
