On 2/20/2008 2:56 AM, [EMAIL PROTECTED] wrote: > 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.)
Thanks. I looked through it for inconsistencies, but obviously I missed the mistake below while doing a substitution. > > 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"? I will ask Tim to add an RFC Editor note. I substituted for Re-authentication Response (that is also wrong). Thanks again Pasi. regards, Lakshminath > > 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
