Document: draft-ietf-emu-eap-arpa Title: The eap.arpa domain and EAP provisioning Reviewer: Ines Robles Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-emu-eap-arpa-06 Reviewer: Ines Robles Review Date: 2025-05-13 IETF LC End Date: 2025-05-13 IESG Telechat date: Not scheduled for a telechat Summary: This document defines the eap.arpa domain as a way for Extensible Authentication Protocol (EAP) peers to signal to EAP servers that they wish to obtain limited and unauthenticated network access. EAP peers indicate the type of access requested by using pre-defined identifiers in the Network Access Identifier (NAI) format defined in RFC 7542. The document is generally well written. I have a few comments and suggestions below for clarification and potential improvements. Comments/Suggestions below as follows: 1- Section 3.5: "...when a provisioning NAI is used, any EAP NAK sent by a server MUST contain only EAP type zero (0)... Similarly, when an EAP peer uses a provisioning NAI and receives an EAP NAK, the contents MUST be ignored." If the peer is required to ignore the content, then it cannot enforce or validate that the received EAP type was 0. Perhaps a clarification would be nice. What about something like: " when an EAP peer uses a provisioning NAI and receives an EAP NAK, the peer MUST ignore any suggested EAP type in the NAK..." ? 2- Section 5.1: "...The device SHOULD ignore the EAP server certificate entirely, as the server's identity does not matter..." 2.1- Would the authors agree that this guidance departs from the TLS security model, where server authentication is generally considered a core security mechanism? 2.2- How does the recommendation to ignore the server certificate align with the guidance in RFC 5216 (Section 5.3), which states that the peer SHOULD perform certificate path validation and MUST ensure that the certificate is appropriate for use with EAP-TLS, 2.3- Could alternative approaches such as pinned certificates (trusting a specific server certificate) or local trust anchors (constraining validation to a preloaded CA set) provide a better trade-off between security and provisioning usability? 3- Section 5.3: "It is RECOMMENDED that EAP-NOOB peers use "@noob.eap.arpa" first, and if that does not succeed, use "noob@xxxxxxxxxxxxx"" 3.1- Why is @noob.eap.arpa preferred? Is it simply newer? Does it offer implementation or operational advantages? Are there any security implications? 3.2- Suppose the server fails to respond to @noob.eap.arpa, and the peer retries with noob@xxxxxxxxxxxxx. Should the peer treat a failure as equivalent to “form not supported” or “provisioning failed”? 3.3- What about rate limiting? Since both identity forms map to EAP-NOOB, should peers be permitted one attempt per NAI form, or should rate limiting apply per EAP method regardless of the NAI used? 4- Section 6.2.1: "The following table gives the initial values for this table." -> The table is not displayed correctly in this section, and it is missing a caption. Nits: “specificatipon” → “specification” “Tf the server...” → “If the server...” “wif the peer...” → “if the peer...” “actoes” → “actors” “poeers” → “peers” “registed” → “registered” “its' access” → “its access” "Section Section 3.4.2" → "Section 3.4.2" Thanks for this document, Ines. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
