Thanks for the review, responses inline: On Mon, Jun 2, 2025 at 6:51 AM Éric Vyncke via Datatracker <[email protected]> wrote:
> Éric Vyncke has entered the following ballot position for > charter-ietf-emu-07-00: Block > > 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.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-emu/ > > > > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- > > Thanks for the rechartering effort, as usual in a charter, I am expecting > to > see the intended status of all work items (probably PS in all the work > items). > > Yes, the intended status is proposed standard, "In summary, the working group shall produce the following standards track documents:" > The charter also mention OoB work but nothing appears to be listed so in > the > work items list. > > [Joe] This work has mostly been completed, EAP-NOOB has been published as RFC 9140 <https://datatracker.ietf.org/doc/rfc9140/>. Also EAP-TLS-POK is a working group item that is also based on out-of-band DPP provisioning - https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/. This work should go to the iESG after I finish the Shepherd writeup for a related TLS spec. If you still think we need to make a change I think we could resolve this by either modifying the following item for EAP-TLS-POK to make it clear that there is an out of band piece "Define mechanisms by which EAP methods can support creation of long-term credentials for the peer based on initial limited-use credentials exchanged out of band." Or we can remove the paragraph about OOB from the charter since it is completed work. > The two above blocking points should be trivial to be addressed. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > And, here are some non-blocking comments: > > Should there be a "used" in `AP is now more broadly in mobile network > authentication` (also noted by Erik Kline) else I cannot parse it. > Yes the sentence should be: "At the same time, some new use cases for EAP have been identified. EAP is now more broadly used in mobile network authentication." > While adding PFS as a requirement, what about post-quantum or randomised > and > changing MAC addresses (with my MADINAS bias here). Should there be some > links > with IEEE 802 work ? > [Joe] We do have an item for the maintenance of existing EAP methods which could cover updates for PQ. Do you think we should call it out specifically? EAP does not deal directly with the MAC address layer, I think it may be distracting to point to MAC address randomization work in the charter. > > I also cannot parse the rather complex (and possibly incomplete) ` for > keeping > the identity provider for that user from tracking what networks or > services a > specific user is accessing` > > Is this better? "An EAP method that provides privacy by preventing a visited network or service from knowing the identity of a user, and for keeping the user's identity provider from tracking what networks or services the user is accessing."
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
