Re: [Emu] AD review of draft-ietf-emu-rfc5448bis-06
Roman, Many thanks for your review. We have gone through all the reviews and comments and are about to post a new draft version in few hours, currently in https://arkko.com/ietf/eap/draft-ietf-emu-rfc5448bis-from--06.diff.html <https://arkko.com/ietf/eap/draft-ietf-emu-rfc5448bis-from--06.diff.html> Here are the responses to your comments: > I conducted an AD review of draft-ietf-emu-rfc5448bis-06 and this document is > in good shape. Thanks for all of the work on it. I have minor questions and > editorial nits which can be addressed with the IETF Last Call feedback. > > Minor: > -- Can you revisit the history -- why was RFC4187 informational? I'm > guessing this draft is informational because it updates RFC4187, right? Yes. And, in addition to what Joe said, the original RFC was informational also because at the time it was not a part of a working group charter but was AD sponsored (albeit it was reviewed and discussed in the EAP working group as well). Considering later events, with hundreds millions or billions of devices supporting this protocol, perhaps it would have been more correct to make it a Proposed Standard. But I don’t think it is worth the effort to change the status now. > -- Section 7.1. Per "The use of pseudonyms in this situation is at best > limited" - unclear to me what this means? Is this say that pseudonyms is not > recommended because the re-use is creates a tracking opportunity (per the > next sentence)? The text was unclear, but the idea is that 5G SUCIs already do a better job here, so downgrading to the possibly multi-use pseudonyms is not wise. Text has been clarified in -07. > -- Section 7.1. Per "Outside 5G, there is a full choice to use ...", what is > a "full choice”? The text has been clarified in -07. > Editorial Nits: > > -- Section 1. s/EAP-AKA' is also an algorithm update for the used hash > functions./EAP-AKA' also updates the algorithm used in the hash functions./ Corrected in -07. > -- Section 1. s/The update ensures/This update ensures/ Corrected in -07. > -- Section 1. Typo. s/how how/how/ Corrected in -07. > -- Section 3.5. Consider giving the table an explicit number (e.g., Table 1) > and s/The attribute table is shown below/The attribute table is shown in > Table 1./ Corrected in -07. > -- Section 5.2. s/However, to ensure privacy/However, to enhance privacy/ -- > there is no "absolute privacy” Corrected in -07. > -- Section 5.2. s/for at attacker/for an attacker/ Corrected in -07. > -- Section 7.3. s/an backwards/a backwards/ Corrected in -07. Jari ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] AD review of draft-ietf-emu-rfc5448bis-06
On Wed, Jan 15, 2020 at 2:24 PM Roman Danyliw wrote: > Hello! > > I conducted an AD review of draft-ietf-emu-rfc5448bis-06 and this document > is in good shape. Thanks for all of the work on it. I have minor > questions and editorial nits which can be addressed with the IETF Last Call > feedback. > > Minor: > -- Can you revisit the history -- why was RFC4187 informational? I'm > guessing this draft is informational because it updates RFC4187, right? > > [Joe] From what I remember EAP-AKA and EAP-SIM were information because the core authentication algorithms and protocols are defined and under the control of 3GPP. You can't implement this spec without those specs, which may imply some intellectual property rights and restrictions. The updates to these documents have kept the informational status. > -- Section 7.1. Per "The use of pseudonyms in this situation is at best > limited" - unclear to me what this means? Is this say that pseudonyms is > not recommended because the re-use is creates a tracking opportunity (per > the next sentence)? > > -- Section 7.1. Per "Outside 5G, there is a full choice to use ...", what > is a "full choice"? > > Editorial Nits: > > -- Section 1. s/EAP-AKA' is also an algorithm update for the used hash > functions./EAP-AKA' also updates the algorithm used in the hash functions./ > > -- Section 1. s/The update ensures/This update ensures/ > > -- Section 1. Typo. s/how how/how/ > > -- Section 3.5. Consider giving the table an explicit number (e.g., Table > 1) and s/The attribute table is shown below/The attribute table is shown in > Table 1./ > > -- Section 5.2. s/However, to ensure privacy/However, to enhance privacy/ > -- there is no "absolute privacy". > > -- Section 5.2. s/for at attacker/for an attacker/ > > -- Section 7.3. s/an backwards/a backwards/ > > Regards, > Roman > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] AD review of draft-ietf-emu-rfc5448bis-06
Hello! I conducted an AD review of draft-ietf-emu-rfc5448bis-06 and this document is in good shape. Thanks for all of the work on it. I have minor questions and editorial nits which can be addressed with the IETF Last Call feedback. Minor: -- Can you revisit the history -- why was RFC4187 informational? I'm guessing this draft is informational because it updates RFC4187, right? -- Section 7.1. Per "The use of pseudonyms in this situation is at best limited" - unclear to me what this means? Is this say that pseudonyms is not recommended because the re-use is creates a tracking opportunity (per the next sentence)? -- Section 7.1. Per "Outside 5G, there is a full choice to use ...", what is a "full choice"? Editorial Nits: -- Section 1. s/EAP-AKA' is also an algorithm update for the used hash functions./EAP-AKA' also updates the algorithm used in the hash functions./ -- Section 1. s/The update ensures/This update ensures/ -- Section 1. Typo. s/how how/how/ -- Section 3.5. Consider giving the table an explicit number (e.g., Table 1) and s/The attribute table is shown below/The attribute table is shown in Table 1./ -- Section 5.2. s/However, to ensure privacy/However, to enhance privacy/ -- there is no "absolute privacy". -- Section 5.2. s/for at attacker/for an attacker/ -- Section 7.3. s/an backwards/a backwards/ Regards, Roman ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
