Hi Alissa, Thanks for your review. I think this commit should address your comments: https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/69dab07b0b1c4dbb303e757c7e06ec6f4775e960
I have also explained the changes made in-line. --Mohit On 1/6/21 8:15 PM, Alissa Cooper via Datatracker wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-emu-eap-tls13-13: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 2.1.3: > > “When NAI reuse can be done without privacy implications, > it is RECOMMENDED to use the same anonymous NAI in the resumption, as > was used in the original full authentication. E.g. the NAI @realm > can safely be reused, while the NAI ZmxleG8=@realm cannot.” > > I think it would help to make this recommendation more specific. Does “without > privacy implications” mean without the username part? Or does it mean > something > else? > > Should this text reference RFC 7542 for further context? The text is now updated to "When NAI reuse can be done without privacy implications, it is RECOMMENDED to use the same anonymous NAI in the resumption, as was used in the original full authentication [RFC7542]. For example, the NAI @realm can safely be reused since it does not provide any specific information to associate a user's resumption attempt with the original full authentication. However, reusing the NAI P2ZIM2F+OEVAO21nNWg2bVpgNnU=@realm can allow a potential attacker to associate a resumption attempt with the original full authentication." > > Section 5.7: > > “Where a good decision is unclear” —> “Where the decision is in doubt” (or > something like that; it isn’t obvious what a “good” decision is) The text is now updated to : " If a safe decision is not possible, EAP-TLS servers SHOULD reject the resumption and continue with a full handshake." > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
